Dies ist eine alte Version des Dokuments!
# Man-in-the-Middle-Angriff bei HTTPS (TLS)
## Ziel des Artikels
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
â ## Beteiligte Rollen
| Rolle | Beschreibung |
|---|---|
| Alice | Client (Browser, App) |
| Bob | Echter HTTPS-Server |
| Mallory | Angreifer im Datenpfad (MITM) |
â ## Wichtige Voraussetzung fĂźr den Angriff
Der Angriff funktioniert nur, wenn Alice das MITM-Zertifikat akzeptiert.
Beispiele:
* Installierte Root-CA (Unternehmens-Proxy, Malware) * Ignorierte Browser-Warnung * Fehlendes Certificate Pinning
â - ## TLS-MITM â Ablauf (ASCII-Sequenzdiagramm, a2s)
â
## Schritt-fßr-Schritt-Erklärung
### 1. Client startet HTTPS
Alice mĂśchte eine HTTPS-Verbindung zu Bob aufbauen.
### 2. MITM Ăźbernimmt die Verbindung
Mallory sitzt im Datenpfad (z. B. WLAN, Proxy, Router) und leitet die Anfrage weiter.
### 3. Bob sendet sein echtes Zertifikat
Bob schickt sein legitimes TLS-Zertifikat an Mallory.
### 4. Mallory erzeugt ein eigenes Zertifikat
* Gleicher Hostname * Eigenes SchlĂźsselpaar * Signiert durch eine CA, der Alice vertraut
### 5. Mallory sendet Fake-Zertifikat an Alice
Alice erhält nicht Bobs Zertifikat, sondern Mallorys.
### 6. Alice prĂźft das Zertifikat
Das Zertifikat wird akzeptiert â Angriff läuft weiter.
â
## đ´ Kritischer Punkt: SitzungsschlĂźssel (korrigiert)
### 7. Alice erzeugt das Pre-Master-Secret
Standard-TLS-Vorgang.
### 8. Alice verschlĂźsselt das Pre-Master-Secret
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
### 9. Mallory entschlĂźsselt das Pre-Master-Secret
Da Mallory den Private Key besitzt, kann sie den SchlĂźssel lesen.
### 10. Mallory startet eine zweite TLS-Verbindung
Mallory baut eine eigene, echte TLS-Verbindung zu Bob auf.
â
## Ergebnis: Zwei getrennte TLS-Tunnel
| Verbindung | Inhalt |
| âââââ | âââââââââââââ |
| Alice â Mallory | Vollständig entschlĂźsselbar fĂźr Mallory |
| Mallory â Bob | Reguläre TLS-Verbindung |
Mallory kann:
* Daten lesen * Daten verändern * Daten neu verschlßsseln
Ohne dass Alice oder Bob es merken.
â
## Merksätze (prßfungsrelevant)
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.
â
## Typische Schutzmechanismen
| 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 đ |
â
## Fazit
Ein MITM-Angriff auf HTTPS ist kein Kryptobruch, sondern ein Vertrauensbruch. Wer die Zertifikatskette kontrolliert, kontrolliert die Verbindung.
â
Wenn du willst, mache ich dir als Nächstes:
* đš eine AP1/AP2-Kurzfassung * đš eine Vergleichsseite: echter TLS-Handshake vs. MITM * đš oder eine âWarum Firmen HTTPS mitlesen dĂźrfenâ-Erklärung
Sag einfach Bescheid.