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:
| Rolle | Beschreibung |
|---|---|
| Alice | Client (Browser, App) |
| Bob | Echter HTTPS-Server |
| Mallory | Angreifer im Datenpfad (MITM) |
Der Angriff funktioniert nur, wenn Alice das MITM-Zertifikat akzeptiert.
Beispiele:
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.
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:
➡ 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.
| Verbindung | Inhalt |
|---|---|
| Alice ↔ Mallory | Vollständig entschlüsselbar für Mallory |
| Mallory ↔ Bob | Reguläre TLS-Verbindung |
Mallory kann:
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.**
**HTTPS-Sicherheit basiert auf Vertrauen in Zertifikate, nicht auf Verschlüsselung allein.**
| Maßnahme | Wirkung |
|---|---|
| HSTS | Erzwingt HTTPS |
| Certificate Pinning | Blockiert fremde Zertifikate |
| Keine fremden Root-CAs | Verhindert Proxy-MITM |
| Benutzer ignoriert Warnungen nicht | effektiv, aber selten 😄 |
Ein MITM-Angriff auf HTTPS ist kein Kryptobruch, sondern ein Vertrauensbruch. Wer die Zertifikatskette kontrolliert, kontrolliert die Verbindung.