© istockphoto.com/Rizvan3d
Logjam und FREAK waren noch lange nicht alles

SSL - der Stand der Dinge


Seit der Veröffentlichung der von Edward Snowden geleakten NSA-Daten ist die Verunsicherung groß [1]: Was kann die NSA entschlüsseln? Wo hat sie bei der Entwicklung von Protokollen und Technologien überall die Finger im Spiel? Was ist noch sicher? Welchen Protokollen kann man noch vertrauen?

Und Sicherheitspolitiker und Strafverfolger haben nichts Besseres zu tun, als auch noch Öl ins Feuer zu gießen und Hintertüren in der Verschlüsselung zu fordern. Dabei haben Logjam und FREAK gerade erst gezeigt, wie gefährlich es ist, wenn man die Verschlüsselung schwächt [2].

2015 war mal wieder ein schlechtes Jahr für SSL/TLS. Nicht nur, dass mit Logjam und FREAK die Folgen der Crypto Wars der 1990er-Jahre ihr hässliches Gesicht zeigten, es wurden auch noch weitere Angriffe vorgestellt – nur, dass die keinen Namen hatten und damit weniger Aufmerksamkeit erregten. Aber zum Glück gibt es auch gute Nachrichten!

Die NSA bricht VPNs mit Logjam auf

Auf dem 32. Chaos Communication Congress (32C3) haben die Entdecker von Logjam erklärt [3], wieso der sehr begründete Verdacht besteht, dass die NSA über Logjam-Angriffe VPN-Verbindungen aufbricht. Es gibt schon länger Gerüchte, dass der NSA ein „großer Durchbruch“ bei der Entschlüsselung gelungen sei, und durch die Snowden-Enthüllungen sind die Budgets der NSA bekannt. Würden für eine bestimmte 1 024-Bit-Primzahl die für einen Logjam-Angriff nötigen Vorberechnungen durchgeführt, könnten die Verbindungen zu 66 Prozent aller VPN-Server und 26 Prozent aller SSH-Server belauscht werden. Die NSA kann es sich leisten, diese Vorberechnungen durchzuführen. Würden auch die Vorberechnungen für eine weitere 1 024-Bit-Primzahl ausgeführt, könnten die Verbindungen von 18 Prozent der Alexa-Top-1-Million-HTTPS-Domains belauscht werden, wofür ebenfalls Geld genug im Budget der NSA vorhanden ist.

Die NSA kann laut der Snowden-Enthüllungen VPN-Verbindungen belauschen. Aufgrund des ebenfalls in den Snowden-Papieren enthaltenen Ablaufs der Entschlüsselung der VPN-Verbindungen und der ebenfalls bekannten Vorbedingungen dafür ist es sehr wahrscheinlich, dass die Entschlüsselung der VPN-Verbindungen über einen Angriff auf den Diffie-Hellman-Schlüsselaustausch erfolgt. Das Letzte, das wir jetzt brauchen können, sind darum neue Schwachstellen in und/oder neue Angriffe auf SSL und TLS. Leider wurden aber genau die 2015 auf den Sicherheitskonferenzen vorgestellt. Logjam und FREAK waren dabei nur die Spitze eines Eisbergs. Der war zwar nicht besonders groß – zum Beispiel gab es im Flash Player sehr viel mehr Schwachstellen, und er wurde auch sehr viel öfter mit 0-Day Exploits angegriffen [4] – aber dafür sind die möglichen Folgen eines Angriffs auf SSL und TLS sehr viel größer als beim Beispiel „Flash Player“. Über den lässt sich immer nur ein Clientrechner kompromittieren, wenn auch beim Einsatz eines 0-Day Exploits als Drive-by-Infektion auf einer viel besuchten Website mitunter sehr viele davon in kurzer Zeit betroffen sind. Bei einem Angriff auf die HTTPS-Verschlüsselung eines Servers sind dagegen gleich sämtliche Benutzer des angegriffenen Servers gefährdet – oder alle geschützten Verbindungen des betroffenen Benutzers, falls sich der Angriff gegen einen bestimmten Benutzer richtet.

Der Einfachheit halber stelle ich die neuen Forschungsergebnisse in chronologischer Reihenfolge vor. Zuvor aber ein wichtiger Hinweis:

RC4 ist tot!

RC4 gilt schon länger als gebrochen, und es sieht ganz danach aus, als ob zumindest die NSA RC4 tatsächlich entschlüsseln kann [2]. RC4 sollte also eigentlich gar nicht mehr verwendet werden. Die IETF hat im Februar 2015 sogar einen RFC veröffentlicht, der die Verwendung von RC4 mit TLS verbietet [5]. Falls Sie noch irgendwo RC4 verwenden, sollten Sie sich also gut überlegen, ob das so bleiben soll, denn sicher ist das nicht.

Zumindest für Webserver gilt sowieso: RC4 ist tot. Die Browserhersteller haben 2015 zudem das Ende der RC4-Unterstützung eingeläutet: Mozilla [6], Google [7] und Microsoft [8] haben sich sogar abgesprochen und im September 2015 gemeinsam das Ende der RC4-Unterstützung für Anfang 2016 angekündigt. Größere Probleme werden nicht erwartet, da der Anteil der RC4-verschlüsselten Verbindungen am gesamten HTTPS-Verkehr im September 2015 bereits verschwindend gering war. Mozilla hat am 26. Januar mit dem Release von Firefox 44 als Erstes einen Browser ohne RC4-Unterstützung veröffentlicht [9]. Das ist auch schon eine der oben erwähnten guten Nachrichten: Zumindest im Web kann RC4 bald niemanden mehr gefährden.

März 2015: Der Bar-Mitzva-Angriff auf RC4

Auf der Black Hat Asia 2015 hat Itsik Mantin einen neuen Angriff auf SSL vorgestellt, den er „Bar-Mitzva Attack“ nennt [10]. Der Angriff richtet sich konkret gegen die Verschlüsselung der Daten mit RC4; ausgenutzt wird eine bereits 2001 entdeckte Schwachstelle, die „Invariance Weakness“ [11]. Da es sich nicht lohnt, einen Angriff auf einen sowieso aussterbenden Algorithmus detailliert zu beschreiben, beschränke ich mich nur auf die möglichen Folgen des Bar-Mitzva-Angriffs. Wird ein schwacher Schlüssel verwendet (von denen es viele gibt), gelangen Teile des Klartexts in die verschlüsselten Daten. Ein Angreifer kann dadurch die Least Significant Bits (LSBs) von bis zu 100 Bytes des Klartexts ermitteln. Das macht das Erraten von Brute-Force-Angriffen auf Passwörter, Kreditkartennummern und Session-Cookies leichter. Jedes Mal, wenn ein geheim zu haltender Wert über eine mit RC4 geschützte TLS-Verbindung übertragen wird

  • besteht eine 1:16 Millionen Chance, dass ein unsicherer Schlüssel verwendet wird

  • besteht eine 1:1 Milliarde Chance, dass ein signifikanter Teil des Geheimnisses verraten wird

Das sind kleine Zahlen, sie sollten zumindest bei ihrer Veröffentlichung aber nicht unterschätzt werden: Im März 2015 wurde noch für ca. 30 Prozent des SSL-Traffics RC4 verwendet. Außerdem weist der Bar-Mitzva-Angriff eine weitere Besonderheit auf: Er ist der erste passive Angriff auf RC4; ein nur lauschender Angreifer kann darüber Daten ausspähen. Alle zuvor vorgestellten Angriffe erforderten einen Eingriff des Angreifers in die Kommunikation, zum Beispiel, um entweder Protokollaushandlungen zu manipulieren oder Code in den Browser des Opfers einzuschleusen.

Mai 2015: illusoryTLS – eine neue Backdoor

Ein großes Problem von SSL/TLS ist das vorhandene Zertifizierungssystem: Es gibt einfach zu viele Zertifizierungsstellen (Certificate Authorities, CA), denen die Browser und Betriebssysteme ab Werk vertrauen. Spielt nur eine einzige davon falsch oder wird sie kompromittiert, entstehen gültige, aber nicht autorisierte Zertifikate, die von den Browsern und Systemen akzeptiert werden.

Alfonso De Gregorio hat auf der „Hack in the Box“ Amsterdam 2015 [12] einen neuen Angriff auf das Zertifizierungssystem vorgestellt: Was passiert, wenn ein Zertifikat eine Hintertür enthält? Konkret geht es um RSA-Schlüssel und deren Zertifikate. Die Sicherheit von RSA hängt davon ab, dass die verwendeten Schlüssel nicht faktorisiert werden können. Indem in den öffentlichen RSA-Schlüssel einer CA mittels elliptischer Kurvenkryptografie (Elliptic Curve Cryptography, ECC) eine Hi...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang