Verhindert HTTPS Man-in-the-Middle-Angriffe vollständig?

Das selbstbewusste „Ja, HTTPS stoppt MITM“ ist die Falle. HTTPS ist darauf ausgelegt, MITM zu stoppen, aber seine Garantien hängen von Annahmen ab, die Angreifer in der realen Welt routinemäßig brechen.

Wann HTTPS MITM tatsächlich verhindert

Wenn der Client die Zertifikatskette bis zu einer CA validiert, der er wirklich vertraut, und das Zertifikat zum Hostnamen passt, dann kann ein Angreifer auf dem Pfad den Server nicht imitieren und den Verkehr nicht lesen. Das ist der vorgesehene, starke Fall — und er hält meist.

Die drei Arten, wie es scheitert

1. Eine bösartige, aber vertraute CA. Unternehmens-TLS-Inspektions-Proxys und manche Malware installieren ihr eigenes Root-Zertifikat im Vertrauensspeicher. Nun kann der Angreifer für jede Website ein gültig aussehendes Zertifikat ausstellen, und der Browser zeigt keine Warnung. Vertrauen ist das gesamte Fundament; untergräbt man den Vertrauensspeicher, wird HTTPS für den Angreifer transparent.
2. Ignorierte Warnungen. Wenn die Validierung fehlschlägt und der Nutzer auf „trotzdem fortfahren“ klickt, hat er das Zertifikat des Angreifers manuell akzeptiert. Abwehrmaßnahmen wie HSTS existieren genau dafür, diese Wegklick-Option zu entfernen.
3. SSL-Stripping. Die erste Anfrage des Opfers ist oft reines HTTP. Ein Angreifer auf dem Pfad fängt sie ab und hält den Nutzer auf HTTP, während er nur mit dem echten Server HTTPS spricht. Mit dem Opfer wird nie TLS aufgebaut, also gibt es nichts zu brechen. HSTS und HTTPS-only-Weiterleitungen mindern das.

Mehrschichtige Abwehr

HSTS (HTTPS erzwingen, kein Wegklicken), Certificate-Pinning und CA-Überwachung (CT-Logs) härten die Grundlage.

Worauf Interviewer achten

Ein differenziertes „Nein, nicht von allein“, mit der Nennung von zumindest SSL-Stripping und dem Rogue-CA-Problem und idealerweise HSTS/Pinning als Härtungsantwort. Absolutismus ist der Fehlermodus.