Workshop: SSL Stripping erkennen und bekämpfen - Teil 1: Grundlagen und Hintergründe

Vertrauensbasis durch TLS-Verschlüsselung

Auf das Konzept des MITM-Angriffs reagierte Netscape im Jahr 1994. Neun Monate, nachdem der erste WWW-Browser Mosaic veröffentlicht worden war, wurde SSL 1.0 als rein firmeninternes Protokoll entworfen. Kurze Zeit später erreichte die Version 2.0 auch die Öffentlichkeit. Die Kanonisierung erfolgte schließlich 1999, als die RFC 2246 eine Weiterentwicklung von SSL 3.0 als TLS 1.0 zum Standard erklärte. Spätere Versionsschritte brachten diverse Verbesserungen bei Sicherheit und Funktionsumfang. Aktuell wird TLS 1.2 eingesetzt.

SSL und TLS verwendeten im Laufe ihrer Geschichte verschiedene jeweils als stark bekannte Verschlüsselungen, und auch das zurzeit eingesetzte AES gilt als nahezu unangreifbar. Dies verhindert ein Abhören der Kommunikation in Echtzeit - es wird erforderlich, die Sicherung zu umgehen.

Um dies zu verhindern, muss der Benutzer sicher sein können, dass er tatsächlich mit dem Zielserver kommuniziert und nicht mit einer Zwischenstelle. Ein Betreiber eines TLS-fähigen Servers kann aus diesem Grund ein Zertifikat seiner persönlichen Identität erwerben. Dieses wird von einer Certificate Authority (CA) ausgestellt und bestätigt, dass der Server einen bestimmten privaten Schlüssel verwendet. Mit diesem privaten Schlüssel erzeugt der Seitenbetreiber nun eine Signatur, die an den Nutzer übertragen wird. Sie kann mit dem öffentlichen Schlüssel der CA auf ihre Zugehörigkeit zum privaten Schlüssel des Betreibers geprüft werden.

Optional sind zudem sogenannte Extended Validation Certificates (EV Certs) erhältlich, bei denen auch die hinter dem Domain-Namen stehende Firma beleuchtet wird. Auch die technischen Vorgaben für den Herstellungsprozess sind für sie schärfer definiert. Sie werden oft für besonders sicherheitskritische Seiten in Auftrag gegeben und finden sich bei vielen Banken oder Regierungsstellen.

Die Zertifizierung hat zwar den Nachteil, dass sie für teures Geld im Abonnement erworben werden muss, doch sie sichert in einer Vielzahl der Fälle gegen einen MITM-Angriff ab. Denn versucht ein Angreifer nun, sich in eine derart geschützte Kommunikation einzuklinken, so ruft er einen Zertifikatfehler hervor. Die von ihm präsentierte Signatur wurde nicht mit dem privaten Schlüssel des Serverbetreibers erstellt, sondern ist als gefälscht zu erkennen. Zumindest theoretisch.

Schwachstellen der TLS

Eine fortgeschrittene Variante dieses Angriffs besteht darin, auch als Angreifer ein Zertifikat zu erwerben, statt sich selbst eines auszustellen. Doch überzeugend gefälschte Bescheinigungen sind nur mit einigem Aufwand zu bekommen. Sie werden entweder von einer zwielichtigen oder schlecht geführten Zertifikatestelle erworben, oder sie fallen bei einem Angriff auf seriöse Stellen als Beute an. Besonderes Aufsehen erregte in diesem Zusammenhang ein Reseller der Comodo CA, der Zertifikate für jede Seite ohne Prüfung ausstellte und sich zudem mit dem Versenden von Spam ein Zubrot verdiente.

Manche Websites kranken zudem immer noch an einem schon längst behobenen Fehler in OpenSSL. Dieser veranlasste den Zufallsgenerator des Programms, nur noch wenige verschiedene Werte auszugeben. Da diese als Basis für den Private Key dienen, wurden für etwa drei Jahre unwissentlich große Mengen wenig zufälliger Schlüssel zertifiziert. Wurde ein solches Zertifikat nicht mittlerweile ausgetauscht und für ungültig erklärt, ist die betroffene Verbindung nicht wesentlich sicherer als eine unverschlüsselte.

Auch der von manchen CAs verwendete Hash-Algorithmus MD5 erwies sich vor einiger Zeit als unsicher. Aufgrund von Kollisionen war es mit massiver Rechenleistung möglich, gefälschte Signaturen und sogar Zertifikate zu erstellen. MD5 befindet sich allerdings auf dem Rückzug. Außerdem ist es nicht gestattet, den Algorithmus bei der EV-Zertifizierung zu verwenden.

Besonders verheerende, aber auch schnell behobene Schwachstellen in der Browsersoftware erinnern zudem immer wieder daran, dass ein Programm grundsätzlich nie als fehlerfrei betrachtet werden kann. So war es beispielsweise lange möglich, universell gültige Wildcard-Zertifikate auszustellen, indem ein Nullbyte im Host-Name-Bezeichner des Zertifikats platziert wurde.

In der Praxis ist als größte Schwachstelle immer auch der Mensch mit einzubeziehen. Viele Nutzer wurden von den langen Zahlenkolonnen der früher üblichen TLS-Fehler abgeschreckt, lasen den Hinweis gar nicht erst und surften einfach weiter. Irgendwann wurde die Fehlermeldung dann schlicht deaktiviert. Zwar haben die bekanntesten Hersteller die Benachrichtigung mittlerweile behutsam modernisiert, indem verschiedene Browser zum Beispiel ihre Adresszeile der Verbindung entsprechend einfärben. Insbesondere auf EV-Zertifikate reagieren viele Programme deutlich. Doch das Verhalten der User ist infolge der häufigen, früher unverständlichen Fehlermeldungen heute entsprechend abgestumpft.

Soweit zu den Hintergründen und zur Problemstellung für den Angreifer. Damit endet der erste Teil unseres Workshops. Unter anderem wird der zweite Teil mit der Durchführung des Angriffs, seiner Erprobung in der Praxis und den Möglichkeiten zur Abwehr befassen. (dre)