Dipl.-Inform. Carsten Eilers

Der aktuellste Angriff wurde Anfang März 2013 veröffentlicht: Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering und Jacob Schuldt haben bewiesen, dass der für die Verschlüsselung verwendete RC4-Algorithmus teilweise gebrochen werden kann, so dass Teile des Klartexts ermittelt werden können. Der Angriff hat die CVE-ID CVE-2013-2566 erhalten.

Konkret können mit dem Angriff zur Zeit die ersten 256 Bytes des Klartext-Streams angegriffen werden. Da die ersten 36 Byte aus einer nicht vorhersagbaren Nachricht des meistens verwendeten Hash-Algorithmus SHA-1 bestehen, können sie nicht ermittelt werden. Effektiv können also 220 Byte eines verschlüsselten Texts entschlüsselt werden. Dafür werden ca. 2³⁰ Sessions benötigt, mit ca. 2²⁴ Sessions können bereits bestimmte Bytes zuverlässig entschlüsselt werden.

Das klingt viel, und das ist es auch. Zumindest zur Zeit ist ein entsprechender Angriff unwahrscheinlich, zumal er erst angepasst werden müsste, um für den Angreifer interessante Daten zu liefern. Zum Beispiel könnte in eine Webseite eingeschleuster JavaScript-Code immer wieder den gleichen HTTPS-URL aufrufen und daraus den Session-Cookie entschlüsseln. Das sind aber nur theoretische Überlegungen, eine praktische Umsetzung gibt es bisher nicht.

Gegenmaßnahmen

Die Streamchiffre RC4 wurde in letzter Zeit sehr häufig für TLS verwendet. Vor allem, weil sie schnell zu berechnen und eine (nun nicht mehr) sichere Alternative für den durch BEAST- und Lucky13-Angriffe (dazu gleich mehr) gefährdeten CBC-Modus von SSL/TLS ist. Inzwischen wurde die CBC-Betriebsart aber gegen BEAST und Lucky13 abgesichert, so dass sie nun als Alternative zu RC4 dienen kann. Sofern Sie eine entsprechend gepatchte Implementierung von TLS 1.0 oder 1.1 verwenden, können Sie den CBC-Modus an Stelle von RC4 für die Verschlüsselung verwenden.

Eine weitere Alternative sind die AEAD-Algorithmen, die mit TLS 1.2 eingeführt wurden. Evtl. führt der Angriff auf RC4 dazu, dass die Verbreitung von TLS 1.2 steigt. Auf lange Sicht gesehen ist diese die beste Lösung.

Theoretisch könnte die Verwendung von RC4 durch TLS geändert werden, zum Beispiel indem der Anfang des RC4-Schlüsselstroms verworfen wird. Praktisch ist dieser Ansatz aber unbrauchbar, da er nur gegen den aktuell implementierten Angriff schützt, nicht aber gegen mögliche Neu- und Weiterentwicklungen. Ganz davon zu schweigen, dass es keine Möglichkeit gibt, innerhalb des TLS-Protokolls so einen Verzicht auszuhandeln, so dass umfangreiche Änderungen an den TLS-Implementierungen auf Clients und Servern nötig wären.

Das gleiche gilt sinngemäß für Änderungen am Browser, mit denen der Angriff weniger effektiv gemacht werden könnte.

TLS und die Lucky 13

Anfang Februar 2013 veröffentlichten Nadhem AlFardan und Kenny Paterson einen Angriff auf die CBC-Verschlüsselung von TLS und DTLS (Datagram Transport Layer Security), genannt "Lucky Thirteen". Der Angriff hat die CVE-ID CVE-2013-0169 erhalten.

Der Angriff nutzt einen Fehler in der TLS-Spezifikation aus und wurde erfolgreich gegen OpenSSL und GnuTLS getestet. Im Fall von OpenSSL konnte der gesamte Klartext ermittelt werden, beim Einsatz von GnuTLS zumindest Teile davon (genauer: 4 Bits des letzten Bytes jedes Klartext-Blocks).

Nadhem AlFardan und Kenny Paterson nutzen dabei dem Umstand aus, dass für bestimmte Nachrichtenlängen die Berechnung des Message Authentication Codes (MAC), mit dem der Klartext vor unerkannten Manipulationen geschützt wird, unterschiedlich lang dauert. Dadurch kann zwischen Nachrichten mit mindestens zwei korrekten Padding-Bytes (mit denen der Block auf die passende Länge aufgefüllt wird) und Nachrichten mit einem korrekten Byte oder einem falsch formatierten Padding unterschieden werden.

Bei den Angriffen handelt es sich um Multi-Session-Angriffe, der gewünschte Klartext muss also mehrmals an der gleichen Stelle im Klartext-Stream in mehreren TLS-Sessions übertragen werden. Durch Manipulationen am vom Angreifer erzeugten Schlüsseltext werden Fehlermeldungen provoziert, aus deren geringen Zeitdifferenzen für verschiedene Manipulationen kann dann statistisch auf den Klartext geschlossen werden.

Beim Test in einem LAN konnte im einfachsten Fall ein kompletter Block des TLS-verschlüsselten Klartexts nach rund 2³² TLS-Sessions ermittelt werden. wenn HMAC-SHA1 als MAC-Algorithmus verwendet wurde (die Komplexität des Angriffs ist von verwendeten MAC-Algorithmus abhängig). Ist bekannt, dass der Klartext Base64-kodiert ist, reichen 2¹⁹ Sessions aus, ist ein Byte des Klartext an einer der letzten zwei Positionen des Blocks bereits bekannt reichen sogar 2¹³ Sessions aus.

Für einen praktischen Angriff auf TLS, vor allem im Web, sind das noch zu viele Sessions, außerdem sind die zu beobachtenden Zeitdifferenzen sehr klein. Allerdings sind auch hier Angriffe über manipulierte Webseiten denkbar. DTLS lässt sich aber bereits angreifen, da dort eine Session nicht sofort beim ersten Fehler beendet wird.

Der Angriff wurde "Lucky 13" genannt, weil bei der MAC-Berechnung 13 Header-Bytes verwendet werden, ohne die der Angriff nicht möglich werden. Obwohl die 13 eigentlich als Unglückszahl gilt, ist sie hier zumindest für den Angreifer eine Glückszahl.

Gegenmaßnahmen

Theoretisch könnten zufällig Verzögerungen Timing-Angriffe erschweren, praktisch klappt das nicht, da auch diese zufälligen Verzögerungen statistisch erfasst werden können, lediglich die Anzahl der für einen Angriff nötigen Sessions würde in die Höhe getrieben.

Als Alternative zur CBC-Verschlüsselung bot sich RC4 an. Bot, da beim Veröffentlichen von Lucky 13 der Angriff gegen RC4 noch nicht bekannt war. Inzwischen sollte man RC4 besser vermeiden, so dass diese Alternative ausscheidet.

Wie im Fall von RC4 ist der Wechsel zu einem der AEAD-Algorithmen wie zum Beispiel AES-GCM möglich.

Zu guter Letzt kann die CBC-Implementierung von TLS so angepasst werden, dass keine Timing Side Channel Angriffe mehr möglich sind.

In den meisten TLS-Implementierungen wie zum Beispiel OpenSSL, NSS, GnuTLS, yaSSL und PolarSSL wurden inzwischen Gegenmaßnahmen gegen den Lucky-13-Angriff implementiert.

CRIME - Der Nachfolger von BEAST

Die BEAST-Entwickler Juliano Rizzo und Thai Duong haben im September 2012 auf der Sicherheitskonferenz ekoparty 2012 unter dem Titel "The CRIME Attack" einen neuen Angriff auf SSL/TLS vorgestellt (Präsentation als PDF).

CRIME steht für "Compression Ratio Info-leak Mass Exploitation" (oder "... Made Easy") und erlaubt es, aus einer HTTPS-Verbindung zum Beispiel Session-Cookies zu entschlüsseln. Voraussetzung für einen erfolgreichen Angriff ist, dass

• der Angreifer den Netzwerk-Traffic des Opfers beobachten kann, zum Beispiel weil beide ein gemeinsames offenes WLAN nutzen und
• das Opfer eine bösartige oder entsprechend präpariere Webseite aufruft. Darüber schleust der Angreifer dann JavaScript-Code in den Browser des Opfers ein, der den Angriff durchführt.

Beides ist natürlich insbesondere erfüllt, wenn der Angreifer als Man-in-the-Middle agieren kann.

Außerdem müssen Client und Server Komprimierung (Compression) verwenden, zum Beispiel die Deflate Compression von TLS oder eine Komprimierung auf Anwendungsebene wie SPDY.

Der Angreifer kann dann die Länge der übertragenen Requests beobachten und durch geschickte Manipulation der gesendeten Daten Teile daraus entschlüsseln oder besser erraten. Wenn vom Angreifer manipulierte Teile des Requests mit zum Beispiel dem Session-Cookie überein stimmen, reduziert sich die Länge des Requests entsprechend. So kann Schritt für Schritt der Wert des Cookies ermittelt werden. Ein Video demonstriert den Angriff.

Gegenmaßnahmen

Der CRIME-Angriff kann verhindert werden, indem die Komprimierung für HTTPS-Verbindungen ausgeschaltet wird. Die Browser wurden, sofern betroffen, inzwischen entsprechend gepatcht.

Fazit

Zusammengefasst kann man sagen, dass SSL/TLS als Protokoll noch lange nicht tot ist, und mit TLS 1.2 steht eine sichere neue Version zur Verfügung.

Beim verwendeten Zertifizierungssystem sieht es schlechter aus, es tauchen zu oft "gefälschte" (besser: zu Unrecht ausgestellte) oder anderweitig problematische Zertifikate auf. Vereinfacht gesagt: Das Zertifizierungssystem beruht auf Vertrauen, und die Zertifizierungsstellen beweisen immer wieder, dass sie kein Vertrauen verdienen. An dieser Stelle besteht also dringender Änderungsbedarf.

Carsten Eilers