Dieser Artikel beschreibt schrittweise, wie ein klassischer Man-in-the-Middle-Angriff (MITM) auf eine HTTPS-Verbindung funktioniert, wenn der Client einem manipulierten Zertifikat vertraut.

Der Fokus liegt auf:

• dem TLS-Handshake
• der Rolle von Zertifikaten
• der korrekten Interpretation der Sitzungsschlüssel-Erzeugung

Beispiele:

• Installierte Root-CA (Unternehmens-Proxy, Malware)
• Ignorierte Browser-Warnung
• Fehlendes Certificate Pinning

  ---

  - ## TLS-MITM – Ablauf (ASCII-Sequenzdiagramm, a2s)

Alice möchte eine HTTPS-Verbindung zu Bob aufbauen.

Mallory sitzt im Datenpfad (z. B. WLAN, Proxy, Router) und leitet die Anfrage weiter.

Bob schickt sein legitimes TLS-Zertifikat an Mallory.

• Gleicher Hostname
• Eigenes Schlüsselpaar
• Signiert durch eine CA, der Alice vertraut

Alice erhält nicht Bobs Zertifikat, sondern Mallorys.

Das Zertifikat wird akzeptiert → Angriff läuft weiter.

Standard-TLS-Vorgang.

Korrekt:

Alice verschlüsselt das Pre-Master-Secret mit dem **öffentlichen Schlüssel aus dem Zertifikat, das sie für das Serverzertifikat hält**.

Wichtig:

• Alice weiß nicht, dass es ein MITM-Zertifikat ist
• Sie verwendet keinen „MITM-Schlüssel“ bewusst

➡ Begriff „MITM-Public-Key“ ist aus Client-Sicht falsch

Da Mallory den Private Key besitzt, kann sie den Schlüssel lesen.

Mallory baut eine eigene, echte TLS-Verbindung zu Bob auf.

Mallory kann:

• Daten lesen
• Daten verändern
• Daten neu verschlüsseln

Ohne dass Alice oder Bob es merken.

**TLS schützt nicht vor MITM, sondern vor unbekannten MITM.**

> **Der Client weiß nie, dass es ein MITM ist – sonst wäre der Angriff gescheitert.**