Kenny Paterson and Nadhem Alfardan haben einen Artikel veröffentlicht, der detailliert eine Methode der Timing Attack gegen SSL beschreibt, die sie Lucky Thirteen tauften. Im Gegensatz zu Rizzo & Duong’s SSL-Attacken (BEAST und CRIME) muss bei Lucky Thirteen kein Code im Browser ausgeführt werden. Mit BEAST und CRIME hat Lucky Thirteen jedoch gemein, dass auf die Charakteristiken der Blockverschlüsselung wie AES abgezielt wird. Eigentlich sind diese Attacken nicht wirklich neu, sie ertasten und nutzen aber kleine Sicherheitslücken, von denen man bisher annahm, dass sie zu klein wären, um ausgenutzt werden zu können.

Als Anbieter von IT-Sicherheitslösungen fragen wir bei F5 uns natürlich, inwiefern unsere Produkte den Lucky Thirteen-Attacken standhalten.

Wir sind zu dem Schluss gekommen, dass die Gefahr, die von Lucky Thirteen ausgeht, für unsere Lösungen als niedrig zu bewerten ist und die Datenebene von F5-Hardware generell nicht anfällig ist. Möglicherweise sind die Management Ports anfällig, die jedoch niemals per Internet zugänglich sein sollten.

Wir sind auch deshalb zu der Überzeugung gelangt, dass die Gefahr als niedrig einzustufen ist, da die Anfälligkeiten unter realen Bedingungen momentan kaum ausgenutzt werden können, was die Autoren auch darstellen.

„In Anbetracht der Komplexität ist eine vollständige Plaintext Recovery Attack auf TLS, zumindest momentan, mehr eine theoretische Bedrohung.“

Der Großteil des SSL Traffics, der von den BIG-IPs abgewickelt wird, ist durch Hardware-Beschleunigung geschützt. Wir haben mit den Autoren daher überlegt, wie und ob der Offload auf spezielle Verschlüsselungs-Hardware uns davor schützt. Die Autoren waren sich nicht sicher und wir einigten uns darauf, dass wir es nicht wissen können, bis wir es getestet haben.

„Wir haben angenommen, dass alle Implementierungen solange gegenüber einfachen Varianten unserer Attacken anfällig sind, bis die Implementierer mit großem Aufwand sicherstellen, dass die Bearbeitungsdauer von Entschlüsselungsvorgängen einheitlich ist. Unsere Erfahrungen beim Aufdecken von Open Source Implementierungen zeigt, dass das unwahrscheinlich ist.“

Wir bei F5 glauben, dass der Offload auf spezielle Verschlüsselungs-Hardware Schutz bietet, weil die Bearbeitung in fast konstanter Zeit stattfindet. Ein weiterer Faktor ist die asynchrone Natur des Offloads. Unser Traffic Management Microkernel (tmm) pusht die SSL Protokolle an den Beschleuniger und geht danach anderen Aufgaben nach. Später kommt er zurück und nimmt die Ergebnisse auf.

Auch wenn ich mich irren kann: Auf dem kryptografischen Level ist das Problem, dass der meiste TLS Code sich etwas anders verhält, wenn unterschiedliche Blöcke von „schlechtem“ Chiffretext entschlüsselt werden. Die Verhaltensauffälligkeit ist minimal, aber durch Sampling, Noise Reduction und Stars Aligning (oder wenigstens MAC Byte Boundaries und Block Sizes Aligning) kann man theoretisch in eine TLS Session einbrechen und den Klartext wiederherstellen, wenn genug Nachrichten mitgelesen wurden. Die „Datagram” Version von TLS (genannt DTLS) ist anfälliger, weil Daten leichter während des Transfers gefälscht werden können.

Wir werden bald wissen, was die Crypto Community über diese Attacken denkt. Ich weiß, das Adam Langley von Google sie sehr ernst nimmt, da die Google Server auf Software SSL Stacks nicht-konstanter Zeit setzen, an denen Paterson und Alfardan ihre Attacken demonstrierten.

Wenn ich eine Vorhersage machen müsste, würde ich sagen, dass Lucky Thirteen neben BEAST und CRIME im kryptografischen Museum für Exploits landet. Sie bekommen viel Aufmerksamkeit, aber echte Attacken konnten kaum beobachtet werden. Da BEAST und CRIME die Einführung von TLS 1.2 antreiben, könnte Lucky Thirteen die Einführung von AES-GCM-Ziffern beschleunigen, die nicht anfällig sind.