© istockphoto.com/dedMazay, © istockphoto.com/Rizvan3d
Schlechte Nachrichten zu SSL und TLS

Protokolle unter Dauerbeschuss


Dass SSL nicht mehr ausreichend sicher ist und durch TLS in einer möglichst hohen Version ersetzt werden sollte, ist seit Längerem bekannt. Wie dringend das ist, wird auf den Sicherheitskonferenzen immer wieder verdeutlicht, und es gibt kaum eine, auf der nicht ein neuer oder zumindest verbesserter Angriff auf SSL/TLS vorgestellt wird.

Besonders ergiebig war 2016 die Black Hat USA. Dort gab es ganze sieben Vorträge, die sich in irgendeiner Form mit SSL/TLS beschäftigten. In gleich zweien davon ging es um die Möglichkeit, SSL/TLS sogar ohne Schwachstelle in Protokollen oder der Implementierung allein durch den Einsatz einer Proxy-Konfiguration zu unterlaufen. Wie das funktioniert, konnten Sie bereits im PHP Magazin 1.17 lesen [1]. Im vorliegenden Artikel dreht sich alles um Schwachstellen in SSL/TLS bzw. seinen Implementierungen und deren Einsatz.

Die Exportkryptografie – gefährlicher als je zuvor

Die „Exportkryptoverfahren“ mit kürzeren Schlüsseln als den damals üblichen, die die USA in den 1990er Jahren für alle aus den USA exportierte Software erzwangen, haben uns ja schon einigen Ärger bereitet. Die 2015 vorgestellten Angriffe Logjam und FREAK [2] sowie der 2016 vorgestellte DROWN-Angriff [3] machten sich alle solche unsicheren Verfahren zu Nutze. David Adrian, der an der Entwicklung von Logjam und DROWN beteiligt war, hat auf der Black Hat USA 2016 in „A Retrospective on the Use of Export Cryptography“ einen Überblick über die Probleme gegeben, die uns die Exportkryptografie bereits beschert hat [4]:

  • FREAK bricht die RSA-Verschlüsselung durch einen Downgrade auf einen Schlüssel für die Exportversion von RSA.

  • Logjam bricht den Diffie-Hellman-Schlüsselaustausch durch einen Downgrade auf eine Primzahl für die Exportversion von DH.

  • DROWN bricht die symmetrische Verschlüsselung, indem das Pre-Master-Secret beim RSA-Schlüsselaustausch über einen Angriff auf die Exportversion von RSA ausgespäht wird.

Adrian hat gezeigt, wie viele Server und Clients von den Schwachstellen betroffen waren, obwohl die kritische SSLv2-Version eigentlich nur ein Jahr eingesetzt und dann von TLS 1.0 abgelöst wurde.

Abgesehen davon, dass sich die Unterstützung obsoleter Kryptoverfahren eindeutig als gefährlich erwiesen hat, zeigen die Angriffe aber auch, dass jede Form geschwächter Kryptografie gefährlich ist. Ende der 1990er Jahre waren NSA und Co. sehr wahrscheinlich in der Lage, die geschwächten Verfahren zu brechen, heute kann das eigentlich jeder. Werden jetzt im Rahmen des neuen Crypto Wars erneut unsichere Verfahren erzwungen, wird sich das darum eher früher als später rächen. Dass man ein eigentlich sicheres Verfahren brechen kann, wenn ein unsicherer Schlüssel verwendet wird, ist nicht weiter verwunderlich. Aber auch mit einem sicheren Schlüssel verschlüsselte Daten lassen sich mitunter ausspähen.

Es war einmal ein Angriff namens CRIME

Im September 2012 wurde von Juliano Rizzo und Thai Duong der CRIME-Angriff auf SSL/TLS vorgestellt [5]. CRIME steht für „Compression Ratio Info-leak Mass Exploitation“ (oder „... Made Easy“). Voraussetzung für den Angriff ist, dass Client und Server eine Komprimierung (Compression) verwenden, zum Beispiel die Deflate Compression von TLS oder eine Komprimierung auf Anwendungsebene wie SPDY. Der Angriff kann von einem MitM durchgeführt werden, um aus einer HTTPS-­Verbindung z. B. Sessioncookies zu entschlüsseln. Dabei werden schrittweise Teile des vermuteten Werts in die Requests eingeschleust und es wird geprüft, wie sich deren Größe nach der Komprimierung verhält. Wurde ein richtiger Wert erraten, wird der Request kürzer, da der erratene Wert für die Komprimierung verwendet werden kann und diese dadurch effektiver wird. Andernfalls wird der nächste Wert ausprobiert und so nach und nach der richtige Wert ermittelt. Der Angriff kann verhindert werden, indem die Komprimierung für HTTPS-Verbindungen ausgeschaltet wird. Die betroffenen Browser wurden sehr schnell entsprechend gepatcht, sodass CRIME-Angriffe schon kurz nach der Vorstellung des Angriffs zumindest mit aktuellen Browsern nicht mehr möglich waren.

Dachte man zumindest. Auf der Black Hat USA 2013 haben Angelo Prado, Neal Harris und Yoel Gluck dann nämlich gezeigt, wie der Angriff weiter genutzt werden kann [6]. Statt der HTTP Requests werden nun die HTTP Responses angegriffen und dabei wird ausgenutzt, dass zwar die Komprimierung auf TLS-Level ausgeschaltet wurde, auf HTTP-Level aber oft weiterhin gzip zum Einsatz kommt. Die Forscher konnten so aus den verschlüsselten Daten zum Beispiel Anti-­CSRF-Tokens extrahieren. Der angepasste Angriff bekam auch einen schönen Namen: BREACH, als Abkürzung von „Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext“. Als Schutz vor den Angriffen müsste man nur die HTTP-Komprimierung komplett ausschalten. Als weitere bzw. alternative Schutzmaßnahmen haben die Forscher z. B. vorgeschlagen, die übertragenen Geheimnisse besser zu schützen, etwa indem sie von Benutzereingaben getrennt, besser maskiert oder für jeden Request zufällig erzeugt werden.

BREACH – auch im März 2016 noch aktuell ...

Warum ich diese ollen Kamellen ausgegraben habe? Weil BREACH auch 2016 noch ein Thema auf den Sicherheitskonferenzen war, und das gleich mehrmals. Im März haben Dionysios Zindros und Dimitris Karakostas „Practical New Developments in the BREACH Attack“ vorgestellt [7]. Der ursprüngliche BREACH-Angriff richtete sich gegen Websites, die

  • HTTPS verwenden,

  • die Response mit gzip komprimieren,

  • eine Stream-Chiffre verwenden,

  • deren Response kein „Noise“ enthält, und

  • einen Endpunkt enthalten, der URL-Parameter reflektiert

Der neue, verbesserte Angriff kann

  • Endpunkte trotz Noise angreifen

  • Blockchiffren wie AES angreifen

Außerdem wurde der Angriff optimiert, sodass er trotz größeren Aufwands noch schnell genug zum Ziel führt. Insbesondere haben sich AES 128 als knackbare Blockchiffre sowie Gmail und Facebook Chat als angreifbare Websites erwiesen. Bei Gmail wurde Schritt für Schritt das Authentifizierungstoken ausgespäht, bei Facebook Chat (das einen guten Schutz der CSRF-Tokens aufweist) betraf es über die Suchfunktion private Chatnachrichten. Zur Durchführung der Angriffe wurde ein Proof of Concept entwickelt: Rupture. Der Angriff auf die Cookies ist möglich, weil der Angreifer die Websites dazu bringen kann, ihm die komprimierten, verschlüsselten Cookies zusammen mit vom Angreifer bestimmtem Klartext zu schicken. Das ist möglich, weil die Cookies auch in Cross-origin Requests mitgeschickt werden. Als Schutz vor diesen und vergleichbaren Angriffen schlagen die Forscher vor, (Authentifizierungs-)Cookies nicht mehr über Domaingrenzen hinweg zu senden. Um das zu erreichen, wurde das Flag „First Party“ für Cookies als Internet-Draft vorgeschlagen [8] und auch schon in Google Chrome experimentell implementiert [9]. Durch Setzen des Flags können die Webserver den Schutz bei Bedarf explizit anfordern, während nicht angepasste Webserver und -anwendungen weiterhin wie gewohnt funktionieren.

... und im August ...

Im August haben Tom Van Goeth...

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