Skip to content

Man-in-the-Middle-Angriffe auf HTTPS

Die CA Trustwave hat ein Zertifikat verkauft, dass Man-in-the-Middle-Angriffe erlaubt. Wie die funktionieren und warum es so schlimm ist, wenn ein offizielles Zertifikat zum Einsatz kommt, erfahren Sie hier.

HTTPS im Einsatz

Bevor wir zum Man-in-the-Middle-Angriff kommen, muss erst mal HTTPS allgemein erklärt werden. Das ist eigentlich ganz einfach: Wenn Sie im Webbrowser durch den Aufruf eines https://-Links eine sichere Verbindung z.B. zu Ihrer Bank aufbauen, stellt Ihr Browser eine Verbindung zum angegebenen Server her, prüft dessen Identität und teilt ihm einen Schlüssel mit, mit dem die nachfolgende Kommunikation verschlüsselt werden soll.

Dabei kommen mehrere Kryptographische Verfahren zum Einsatz: Eine Public-Key-Infrastruktur, um die Identität des Servers zu prüfen und dessen öffentlichen Schlüssel zu erhalten, ein asymmetrisches Kryptosystem, mit dem der vom Webbrowser erzeugte Sitzungsschlüssel sicher an den Server gesendet wird, und ein symmetrisches Kryptosystem, mit dem danach alle übertragenen Daten verschlüsselt werden. Aufgeteilt in die einzelnen Schritte sieht das so aus, siehe auch Abb. 1:

  1. Sie geben im Browser https://www.ihre-bank.example ein.
  2. Ihr Browser baut eine Verbindung zum Webserver www.ihre-bank.example auf.
  3. Der Webserver sendet sein Zertifikat mit seinem öffentlichen Schlüssel an Ihren Browser.
  4. Ihr Browser prüft das Zertifikat. Dazu enthält er ab Werk eine Liste von aus Sicht des jeweiligen Browserherstellers vertrauenswürdigen CAs. Wurde das Zertifikat nicht von einer dieser CAs ausgestellt oder ist die Signatur nicht korrekt, gibt er eine Warnung aus und beendet den Verbindungsaufbau.
  5. Verläuft die Prüfung erfolgreich, weiß der Browser, dass er wirklich mit dem Server www.ihre-bank.example verbunden ist und kennt dessen öffentlichen Schlüssel. Nun erzeugt er einen symmetrischen Schlüssel, der nur für die aktuelle Sitzung verwendet wird, den sog. Sitzungsschlüssel oder Session Key.
  6. Der Sitzungsschlüssel wird mit dem öffentlichen Schlüssel des Webservers verschlüsselt und an den Webserver übertragen.
  7. Der Webserver entschlüsselt den Sitzungsschlüssel mit seinem privaten Schlüssel.
  8. Jetzt besitzen sowohl Webbrowser als auch Webserver einen gemeinsamen Schlüssel für das symmetrische Kryptosystem, mit dem sie alle weiteren zu übertragenen Daten verschlüsseln können.
  9. Der Webserver baut seine Startseite auf, verschlüsselt sie mit dem Sitzungsschlüssel und sendet sie an den Browser.
  10. Der Browser entschlüsselt die verschlüsselte Startseite und stellt sie dar.
  11. Auch alle weiteren zu übertragenen Daten werden mit dem Sitzungsschlüssel verschlüsselt.

HTTPS
Abb. 1: HTTPS (Klick öffnet ein größeres Bild in einem neuen Fenster)

Man-in-the-Middle-Angriff auf HTTPS, allgemein

Betrachten wir nun einen MitM-Angriff auf obiges Beispiel, z.B. durch ein Data Loss Prevention System (DLP-System) wie dass, für das Trustwaves "MitM-Zertifikat" verwendet wurde. Zuerst aber ohne das "MitM-Zertifikat". Damit der Man-in-the-Middle eine HTTPS-Verbindung aufbauen kann, braucht er aber ein passendes Zertifikat, in diesem Fall für www.ihre-bank.example. Das kann er sich selbst erstellen und auch selbst signieren, so dass es formal korrekt ist.

  1. Sie geben im Browser https://www.ihre-bank.example ein
  2. Ihr Browser baut eine Verbindung zum Webserver www.ihre-bank.example auf.
  3. Der Man-in-the-Middle nimmt die Verbindungsanfrage entgegen. Er sendet sein gefälschtes Zertifikat für https://www.ihre-bank.example mit seinem öffentlichen Schlüssel an Ihren Browser.
    Parallel baut er eine HTTPS-Verbindung zu https://www.ihre-bank.example auf, wie es oben beschrieben wurde.
  4. Ihr Browser prüft das Zertifikat. Da es zwar zu www.ihre-bank.example gehört, aber von einer unbekannten CA unterzeichnet wurde, gibt er eine Warnung aus. Sie bemerken den Angriff und hören mit dem Surfen auf.
    Oder sie fallen auf das gefälschte Zertifikat herein, halten es für echt und surfen weiter. Dann haben Sie Pech gehabt, denn der MitM kann alle übertragenen Daten ausspähen und/oder manipulieren, s.u..

Im Fall eines DLP-Systems ist es üblich, eine eigene PKI aufzubauen und das zugehörige Root-Zertifikat, mit dem die ausgestellten Zertifikate geprüft werden, in den internen Webbrowsern zu installieren. Parallel werden die Benutzer über das Aufbrechen der geschützten Verbindung informiert. Dann würde der MitM-Angriff so ablaufen:

  1. Sie geben im Browser https://www.ihre-bank.example ein
  2. Ihr Browser baut eine Verbindung zum Webserver www.ihre-bank.example auf.
  3. Das DLP-System nimmt die Verbindungsanfrage entgegen. Es erstellt ein Zertifikat für www.ihre-bank.example mit seinem öffentlichen Schlüssel, signiert es mit dem Root-Schlüssel der internen PKI und sendet es an Ihren Browser.
    Parallel baut es eine HTTPS-Verbindung zu https://www.ihre-bank.example auf, wie es oben beschrieben wurde.
  4. Ihr Browser prüft das Zertifikat. Da es zu www.ihre-bank.example gehört und von der ihm bekannten internen Zertifizierungsstelle ausgestellt wurde, gibt er keine Warnung aus, sondern baut die Verbindung weiter auf.
  5. Ihr Browser tauscht mit dem DLP-System, den er für den Bank-Server hält, einen Sitzungsschlüssel aus.
  6. Jetzt besitzen sowohl Webbrowser und DLP-System als auch DLP-System und Webserver jeweils einen gemeinsamen Schlüssel für das symmetrische Kryptosystem, mit dem sie alle weiteren zu übertragenen Daten verschlüsseln können.
  7. Der Webserver baut seine Startseite auf, verschlüsselt sie mit dem mit dem DLP-System vereinbarten Sitzungsschlüssel und sendet sie an das DLP-System (das er für Ihren Browser hält).
  8. Das DLP-System entschlüsselt die Daten und kann sie nun prüfen und ggf. manipulieren. Sollen die Daten das DLP-System passieren, werden sie mit dem zwischen DLP-System und Webbrowser ausgetauschten Schlüssel verschlüsselt und an den Browser gesendet. Der denkt, sie stammen von www.ihre-bank.example und sind unverändert!
  9. Der Browser entschlüsselt die verschlüsselte Startseite und stellt sie dar.
  10. Auch alle weiteren zu übertragenen Daten werden entsprechend verschlüsselt, vom DLP-System entschlüsselt und nach der Prüfung erneut verschlüsselt.

Nehmen wir mal an, ein Gast benutzt Ihr lokales Netz und surft seine Bank an. Da sein Browser natürlich nicht das Root-Zertifikat der internen PKI kennt, passiert das gleiche wie im ersten Angriffs-Beispiel: Der Browser bemängelt die unbekannte Zertifizierungsstelle und die Verbindung wird abgebrochen.

MitM-Angriff mit "MitM-Zertifikat"

Kommen wir nun zu einem MitM-Angriff mit einem "MitM-Zertifikat" einer "offiziellen" Zertifizierungsstelle, deren Root-Zertifikat in allen Webbrowern enthalten ist, siehe auch Abb. 2:

  1. Sie geben im Browser https://www.ihre-bank.example ein
  2. Ihr Browser baut eine Verbindung zum Webserver www.ihre-bank.example auf.
  3. Der MitM nimmt die Verbindungsanfrage entgegen. Es erstellt ein Zertifikat für www.ihre-bank.example mit seinem öffentlichen Schlüssel, signiert es mit dem Root-Schlüssel zum "MitM-Zertifikat" und sendet es an Ihren Browser.
    Parallel baut es eine HTTPS-Verbindung zu https://www.ihre-bank.example auf, wie es oben beschrieben wurde.
  4. Ihr Browser prüft das Zertifikat. Da es zu www.ihre-bank.example gehört und von einer ihm bekannten "offiziellen" Zertifizierungsstelle ausgestellt wurde, gibt er keine Warnung aus, sondern baut die Verbindung weiter auf.
  5. Ihr Browser tauscht mit dem MitM einen Sitzungsschlüssel aus.
  6. Jetzt besitzen sowohl Webbrowser und MitM als auch MitM und Webserver jeweils einen gemeinsamen Schlüssel für das symmetrische Kryptosystem, mit dem sie alle weiteren zu übertragenen Daten verschlüsseln können.
  7. Der Webserver baut seine Startseite auf, verschlüsselt sie mit dem mit dem MitM vereinbarten Sitzungsschlüssel und sendet sie an den MitM (den er für Ihren Browser hält).
  8. Der MitM entschlüsselt die Daten und kann sie nun lesen und ggf. manipulieren. Sollen die Daten an den Browser weitergeleitet werden, werden sie mit dem zwischen MitM und Webbrowser ausgetauschten Schlüssel verschlüsselt und an den Browser gesendet. Der denkt, sie stammen von www.ihre-bank.example und sind unverändert!
  9. Der Browser entschlüsselt die verschlüsselte Startseite und stellt sie dar.
  10. Auch alle weiteren zu übertragenen Daten werden entsprechend verschlüsselt, vom MitM entschlüsselt und nach der Prüfung erneut verschlüsselt.

MitM-Angriff auf HTTPS mit MitM-Zertifikat
Abb. 2: MitM-Angriff auf HTTPS mit "MitM-Zertifikat" (Klick öffnet ein größeres Bild in einem neuen Fenster)

Der angenommene Gast würde von diesem MitM-Angriff nichts bemerken, da das gefälschte Zertifikat von einer "offiziellen" Zertifizierungsstelle ausgestellt wurde, deren Root-Zertifikat in seinem Webbrowser gespeichert ist.

MitM-Angriff mit "MitM-Zertifikat" "in the wild"

Betrachten wir den MitM-Angriff mit "MitM-Zertifikat" mal außerhalb geschlossener lokaler Netze, also "in the wild". Was wäre, wenn ein Cyberkrimineller so ein "MitM-Zertifikat" besäße? Er könnte jede beliebige HTTPS-Verbindung, die über einen von ihm kontrollierten Server läuft, aufbrechen, ohne dass der Benutzer es merkt. Und gerade das ist der entscheidende Punkt: Das "MitM-Zertifikat" erlaubt es dem Inhaber, gültige Zertifikate für beliebige Domains zu erstellen, die von den Webbrowsern problemlos anerkannt werden. Er ist also quasi seine eigene, offiziell anerkannte Zertifizierungsstelle. Denn für genau diesen Zweck ist diese Sorte von Zertifikaten, die eigentlich als "Intermediate Zertifikat" bezeichnet wird, normalerweise vorgesehen: Eine Zertifizierungsstelle kann damit einer weiteren, untergeordneten Zertifizierungsstelle das selbständige Ausstellen von Zertifikaten ermöglichen. Um so schlimmer ist ein Missbrauch wie im Fall von Trustwave.

Und nun betrachten Sie das Problem mal mit anderen Inhabern von "MitM-Zertifikaten", z.B. Strafverfolgungsbehörden oder Regierungen bestimmter Länder...

MitM-Angriff mit "MitM-Zertifikat" erkennen

Die einzige zuverlässige Möglichkeit, so einen Angriff zu bemerken, ist der Vergleich des Zertifikats-Fingerprints mit dem korrekten Fingerprint - sofern man ihn denn kennt. Banken teilen den Fingerprint ihren Kunden teilweise mit, aber die wenigsten prüfen ihn, erst recht nicht bei jedem Verbindungsaufbau. Und die Fingerprints der Zertifikate von z.B. Google oder Microsoft kennt außerhalb der Unternehmen wohl kein Mensch.

Ansonsten ist das einzig Auffällige an dem Angriff der "falsche" Aussteller z.B. des Bank-Zertifikats. Wenn der Benutzer weiß, dass die Bank ein Zertifikat von Zertifizierungsstelle A hat und sie nun plötzlich angeblich eines von Zertifizierungsstelle B verwendet, könnte ein Angriff vorliegen. Oder die Bank die Zertifizierungsstelle gewechselt haben.

Wichtig ist die Identitätsprüfung

Nur noch mal zur Verdeutlichung: Wichtig ist beim HTTPS-Protokoll die Identitätsprüfung des Servers. Ist die nicht zuverlässig, könnten Webbrowser und Webserver auch einfach einen Schlüssel mit Hilfe des Diffie-Hellman- Schlüsselaustausch vereinbaren und sich den Aufwand der Zertifikatsprüfung und des Zertifizierungssystems sparen. Der Schlüsselaustausch und das Verschlüsseln sind keine Kunst, die Identitätsprüfung ist das entscheidende Kriterium. Wenn man nicht sicher weiß, dass man wirklich z.B. mit dem Server der eigenen Bank verbunden ist, ist es im Grunde sogar egal, ob die Verbindung verschlüsselt ist oder nicht - dann kann wirklich alles passieren.

In der nächsten Woche findet die CeBIT statt, auf der ich einige Termine habe. Wenn ich es zeitlich schaffe, gibt es daher nächste Woche einen Bericht von der CeBIT.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : Flame und die Windows-Updates

Vorschau anzeigen
An Flame war ja anfangs eigentlich nichts besonderes, wenn man mal von der Größe und der Unfähigkeit der Antivirenhersteller, diesen Riesenschädling zeitnah zu entdecken, absieht. Einzig interessant schien die zumindest anf

Dipl.-Inform. Carsten Eilers am : Mahdi wird zum Bettvorleger, und Passwortlecks sind der Sommerhit 2012

Vorschau anzeigen
Ohne viel Vorrede gleich zum Thema: Mahdi - Ein digitaler Bettvorleger? Keinen großen Kommentar gibt es zu Mahdi. Aus dem einfachen Grund, dass es keine neuen Erkenntnisse darüber gibt. Sie haben richtig gelesen: Außer Ka

Dipl.-Inform. Carsten Eilers am : SSL - Der nächste Nagel im Sarg?

Vorschau anzeigen
Es gibt mal wieder schlechte Nachrichten über SSL. Diesmal wurde mal keine Zertifizierungsstelle gehackt, stattdessen haben Forscher festgestellt, dass die Prüfung von Zertifikaten in anderer Software als Webbrowsern ziemlich mangelhaft

Dipl.-Inform. Carsten Eilers am : SSL/HTTPS - Schon wieder schlechte Nachrichten

Vorschau anzeigen
Es gibt schon wieder schlechte Nachrichten zu SSL bzw. konkret zu HTTPS: Da wird von den Webservern nicht so sicher eingesetzt, wie es eigentlich nötig wäre. Dadurch sind in sehr vielen Fällen SSL-Stripping-Angriffe möglich.

Dipl.-Inform. Carsten Eilers am : Code Signing - Auch Schadsoftware kann signiert sein

Vorschau anzeigen
Oracles Antwort auf Javas ständige Sicherheitsprobleme: Der Einsatz von Code Signing. Vorerst gibt es nur mehr oder weniger ausführliche Warnungen vor nicht oder falsch signierten Applets, irgendwann sollen dann nur noch signierte Apple

Dipl.-Inform. Carsten Eilers am : Kommentare zu diesem und jenem

Vorschau anzeigen
Heute gibt es Kommentare zu einem Root-Zertifikat des US-Verteidigungsministeriums, einem neuen Java-Exploit, die 0-Day-Exploits aus dem 1. Quartal, Passwort-Recycling in Großbritannien und einem unerwarteten Support-Ende für Windows XP.

blog.atari-frosch.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

Dipl.-Inform. Carsten Eilers am : NSA: Nicht die Krypto-Verfahren, sondern ihre Implementierungen sind unsicher

Vorschau anzeigen
Guardian, New York Times und ProPublica haben berichtet. dass die NSA viele Krypto-Verfahren, darunter SSL, entschlüsseln kann. Das bedeutet aber nicht, dass diese Verfahren gebrochen sind. Die Kryptographie-Verfahren sind sicher Ei

Dipl.-Inform. Carsten Eilers am : HTTP Request Hijacking - Ein neuer Angriff unter der Lupe

Vorschau anzeigen
Da HTTP Request Hijacking (HRH) es sogar in die Nachrichten geschafft hat und dort für etwas Panikmache genutzt wird, möchte ich mal ein paar Fakten liefern. Wie funktioniert HRH, und wie gefährlich ist so ein Angriff? HTTP Reque

jaxenter.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

Dipl.-Inform. Carsten Eilers am : SSL/TLS - Mal wieder einige schlechte Nachrichten!

Vorschau anzeigen
Heute gibt es mal wieder einige Nachrichten rund um SSL/TLS und das Zertifikatssystem. Natürlich schlechte. Gab es dazu eigentlich auch mal gute Nachrichten? Erinnern kann ich mich gerade an keine. Eine CA verspielt das in sie gesetzte Ve

entwickler.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

entwickler.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

Dipl.-Inform. Carsten Eilers am : XSS-Angriffe, Teil 9: Der Router im Visier

Vorschau anzeigen
Ein Portscan mit JavaScript ist kein größeres Problem. Egal ob mit normalen JavaScript für einen Host oder einen IP-Adressbereich oder mit Hilfe der HTML5-JavaScript-APIs, die Suche nach Rechnern im lokalen Netz des angegriffene

Dipl.-Inform. Carsten Eilers am : Drucksache: PHP Magazin 5.2015 - Logjam und FREAK gefährden TLS

Vorschau anzeigen
Im PHP Magazin 5.2015 ist ein Artikel über die neuen Angriffe auf TLS erschienen: Logjam und FREAK. Die schwachen Krypto-Verfahren mit viel zu kurzen Schlüsseln, die viele Clients und Server aus historischen Gründen unterst&uu

Dipl.-Inform. Carsten Eilers am : Microsoft hat Patchday, und wie üblich werden 0-Days behoben

Vorschau anzeigen
Am Dezember-Patchday hat Microsoft mal wieder 0-Day-Schwachstellen behoben. Zwar "nur" 3, aber 2 davon werden bereits für Angriffe ausgenutzt. Codeausführung in MS Office Die erste bereits für Angriffe ausgenutzte 0-Day-Schwac

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

t001 am :

Vielen Dank für diese ausführliche Erklärung MitM-Zertifikate. Ein sehr spannendes Thema! Ich war übrigens auch auf der CeBIT und habe mich von den Jungs beim täglichen CACERT-Treffen bestätigen lassen;) Leider wurden die von Mozilla noch nicht als Instanz anerkannt.
 
Noch ein Hinweis auf kein gutes Plugin: Zertificate Patrol von Firefox gibt auch Bescheid, wenn sich ein Zertifikate ändert. Es kann einem also vor falschen Zertifikaten warnen, wenn man das „richtige” schon mal verwendet hat.

Carsten Eilers am :

Danke für das Lob.

CAcert ist ja eigentlich auch ein Teil des Problems, das ganze CA-System ist hinüber. Und so schnell wird CAcert bei Mozilla nicht rein kommen, die dürften kaum einen Audit bestehen.

Eigentlich müssten die Browser- und Systemhersteller mal bei allen CAs Druck machen: Erfolgreicher Audit (unter möglichst scharfen Bedingungen) oder sie fliegen raus.

Zertificate Patrol ist ganz gut, für Normalbenutzer ist der Ansatz aber nicht besonders brauchbar. Zertifikate wechseln ja auch ohne Angriff von Zeit zu Zeit, ein normaler Benutzer kann dann kaum prüfen, ob das neue Zertifikat korrekt ist oder ob es ein Angriff ist.

Tom am :

Ich finde Zertificate Patrol sehr brauchbar auch für den Normalbenutzer.
Eine Kontrolle würde ich persönlich doch nur vornehmen, wenn Zertificate Patrol Alarm gibt
z.B. bei Paypal, Bank und Ebay also wichtigen Seiten wo Geld im Spiel ist. Bei einem Alarm kann ich dann die Fingerprints, die jede Bank öffentlich macht vergleichen.
Nur Google nervt in Verbindung mit dem Plug-In die haben unzählige Zertifikate im Einsatz und bringen bei mir stets Alarmmeldungen.

Guter Beitrag übrigens und sehr verständlich. Um das ganze Abzurunden fehlt nur noch die technische Erklärung wie es zu einem Man-in-the-Middle-Angriff überhaupt kommen kann. Also DNS Server Injektion, manipulation der hosts Datei, Phishing usw.

Carsten Eilers am :

Ich habe die Erfahrung gemacht, dass die meisten normalen Benutzer mit Warnungen überfordert sind. Und im Zweifelsfall wird dann halt auch ein gefälschtes Zertifikat akzeptiert, damit man das machen kann, was man machen will. Frei nach dem Motto "Das hat immer funktioniert, wenn da was nicht stimmt, ist bestimmt der Browser kaputt".

Und Google und die Zertifikate - manchmal glaube ich, die wissen selbst nicht genau, wo sie welches Zertifikat (und warum) verwenden. Da müsste mal gründlich ausgemistet werden.

Danke für das Lob. "Wie kommt der Man in die Middle" sollte ich wirklich mal beschreiben. Mal sehen, wann ich dafür Zeit finde.

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Formular-Optionen

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!