SSL/TLS: Schwächen in RC4 ausnutzbar
Seit gestern macht eine Präsentation des Kryptografen Dan J. Bernstein(öffnet im neuen Fenster) Furore. Was Bernstein berichtet, hat Sprengkraft: Auf der aktuell stattfindenden Konferenz Fast Software Encryption in Singapur stellt der Professor der University of Illinois einen Angriff gegen die RC4-Verschlüsselung in TLS(öffnet im neuen Fenster) vor.
TLS (oft noch unter dem alten Namen SSL bekannt) ist das mit Abstand am häufigsten genutzte Verschlüsselungsprotokoll im Internet. Jedes Mal, wenn eine Webseite über https aufgerufen wird, kommt TLS zum Einsatz. Zuletzt geriet das Protokoll stark unter Beschuss.
RC4: Schnell, aber nicht besonders sicher
Dass RC4 kein besonders sicheres Verschlüsselungsverfahren ist, ist schon länger bekannt. Es handelt sich dabei um eine sogenannte Stromverschlüsselung, die ursprünglich vom Kryptografen Ron Rivest entwickelt wurde. Rivest hatte eigentlich keine Veröffentlichung von RC4 geplant, aber 1994 wurde der Quellcode der RC4-Verschlüsselung auf einer Mailingliste anonym veröffentlicht. RC4 erfreute sich schnell großer Beliebtheit, denn es ist relativ simpel zu implementieren und arbeitet sehr schnell.
Bei einer Stromverschlüsselung wird durch einen Pseudozufallszahlengenerator ein Schlüsselstrom erzeugt, der mit dem zu verschlüsselnden Text per XOR verknüpft wird. Das Problem von RC4: Der Zufallsstrom ist nicht immer zufällig. Schnell fanden Kryptografen heraus, dass an bestimmten Stellen im Schlüsselstrom bestimmte Bits mit einer höheren Wahrscheinlichkeit auftauchen.
Genau diese Schwäche nutzt nun der neue Angriff aus. Notwendig für den Angriff ist eine große Zahl von Datenblöcken, die mit denselben Daten anfangen. Das ist beispielsweise bei HTTPS-Verbindungen oft der Fall. Die Autoren sprechen von 2 hoch 30 Datenverbindungen, was mehrere GByte an Daten bedeuten würde. Aber bereits bei 2 hoch 24 Verbindungen könne man Rückschlüsse auf bestimmte Bytes im Datenstrom ziehen. Für einen Angriff auf Webapplikationen ist das unter Umständen bereits genug. Details des Angriffs wollen die Autoren in Kürze in einem Paper veröffentlichen.
Wie praktikabel ein solcher Angriff in realen Szenarien ist, wird sich also erst noch zeigen, aber die Autoren warnen schon jetzt, dass sie auf jeden Fall damit rechnen, dass weitere Forschung die Angriffe noch deutlich verbessern wird.
Auch CBC hat Schwächen
TLS unterstützte eine ganze Reihe unterschiedlicher Verschlüsselungsalgorithmen. RC4 ist das einzige unterstütze Stromverschlüsselungsverfahren, alle anderen Verfahren wie AES, Triple-DES oder Camellia sind sogenannte Blockverschlüsselungen. In der bis heute meistens eingesetzten TLS-Version 1.0 und auch beim Nachfolger TLS 1.1 nutzen alle Blockchiffreverfahren den sogenannte Cipher Block Chaining-Modus (CBC). Die Angriffe BEAST und Lucky Thirteen nutzten Schwächen in CBC beziehungsweise in der Art, wie CBC innerhalb von TLS genutzt wird, aus.
Besonders problematisch ist die Tatsache, dass in TLS CBC in Kombination mit der sogenannten HMAC-Authentifizierung und die Authentifizierung nach der Verschlüsselung eingesetzt wird. Bei früheren TLS-Implementierungen konnte ein Angreifer aufgrund der Fehlermeldung herausfinden, ob die Dekodierung eines Blocks bei der Überprüfung der HMAC-Authentifizerung oder der Datenentschlüsselung scheiterte. Mit Hilfe gezielt eingestreuter fehlerhafter Datenblöcke konnte so ein Angreifer Rückschlüsse auf den Schlüssel ziehen. Später wurde diese Fehlermeldung vereinheitlicht, doch aufgrund der Antwortzeit des Servers war es immer noch möglich, Rückschlüsse zu ziehen. Das war die Grundlage der Lucky-Thirteen-Attacke.
RC4 und CBC mit Problemen, der Ausweg heißt TLS 1.2
Bis vor kurzem galt häufig die Empfehlung: Da CBC viele Probleme bereitet, sollte man vorübergehend nur noch auf RC4 setzen. So fordert etwa der von der Kreditkartenbranche geforderte Sicherheitsstandard PCI-DSS, alle CBC-basierten Verschlüsselungsalgorithmen abzuschalten. Auch große Webseiten wie Google setzen bislang auf RC4 als primären Algorithmus und ein viel beachteter Online-Test für HTTPS-Server(öffnet im neuen Fenster) von der Firma Qualys empfiehlt zur Vermeidung der BEAST-Attacke, RC4-Algorithmen in der Serverkonfiguration zu bevorzugen.
Eine Empfehlung, vor der nun andere warnen. "Hört zu, wenn ihr RC4 als bevorzugten Verschlüsselungsalgorithmus in SSL/TLS benutzt, wäre jetzt ein guter Zeitpunkt damit aufzuhören" , schreibt etwa der Kryptograf Matthew Green in seinem Blog(öffnet im neuen Fenster) .
Die Schwächen in CBC sind inzwischen in allen gängigen SSL-Implementierungen wie OpenSSL, GnuTLS oder nss behoben. Wichtig ist allerdings, von den jeweiligen Bibliotheken nur die aktuellen Versionen einzusetzen. Ein gutes Gefühl kommt dabei dennoch nicht auf. Denn auch die Autoren der erst im Februar bekanntgewordenen Lucky-Thirteen-Attacke warnten: Sie rechnen mit weiteren Verbesserungen ihrer Angriffsmethode.
Der Ausweg: TLS 1.2 und der Galois/Counter-Modus
Der einzig saubere Ausweg wäre es, sowohl auf RC4 als auch auf Blockchiffren mit CBC komplett zu verzichten. Das Problem dabei: Das ist lediglich mit der TLS Version 1.2 möglich. Dort wurde die AES-Verschlüsselung in Kombination mit dem sogenannten Galois/Counter-Modus (GCM) eingeführt. Im Unterschied zu CBC gewährleistet GCM sowohl Verschlüsselung als auch Authentifzierung in einem Schritt. Alle Schwächen, unter denen CBC leidet, sind bei GCM somit ausgemerzt.
Der optimale Ausweg wäre also der Einsatz von TLS 1.2. Doch obwohl dieser Standard als RFC 5246(öffnet im neuen Fenster) bereits 2008, also vor über vier Jahren, veröffentlicht wurde, kann bislang kaum ein Browser damit umgehen. Für die von Firefox eingesetzte nss-Bibliothek existiert lediglich ein experimenteller Patch(öffnet im neuen Fenster) . Der Internet Explorer und Opera unterstützen theoretisch TLS 1.2, allerdings ist die Nutzung in der Standardkonfiguration abgeschaltet. OpenSSL unterstützt TLS 1.2 seit der Version 1.0.1, die im vergangenen Jahr veröffentlicht wurde. Ältere OpenSSL-Versionen sind noch häufig im Einsatz.
Für Serveradministratoren gilt damit: Sie sollten auf jeden Fall dafür sorgen, dass ihre Systeme TLS 1.2 so schnell wie möglich unterstützen. Die Abschaltung der früheren TLS-Versionen ist allerdings auf absehbare Zeit kaum eine realistische Option.
Die Autoren der neuen Attacke empfehlen vorübergehend, RC4 zu deaktivieren und wieder auf die CBC-Modi zu setzen. Hierfür sollte gewährleistet sein, dass aktuelle Versionen der SSL-Bibliotheken eingesetzt werden, damit Korrekturen, die im Zuge der BEAST- und Lucky-Thirteen-Angriffe vorgeschlagen wurden, zum Einsatz kommen.