Erste Lösungen für SSL/TLS-Schwachstelle

Sicherheitsspezialisten schlagen vor, Webserver auf Stromchiffrieralgorithmen umzustellen. Google arbeitet derweil an einem Fix für Chrome.

In Pocket speichern vorlesen Druckansicht 78 Kommentare lesen
Lesezeit: 3 Min.
Von
  • Daniel Bachfeld

Als Abhilfe gegen die vergangene Woche einer größeren Öffentlichkeit bekannt gewordene Schwachstelle in SSL/TLS wird von Sicherheitsspezialisten der Einsatz von RC4 vorgeschlagen. Der Stromchiffrieralgorithmus nutzt anders als AES, das auf den meisten Servern zum Einsatz kommt, keinen Cipher-Block-Chaining-Mode (CBC). CBC ist aber, so wie er bis SSL 3.0/TLS 1.0 implementiert ist, gegen sogenannte Chosen-Plaintext-Attacken anfällig.

Kern des Problems sind die nicht für jeden Block zufällig erzeugten Initialisierungsvektoren (IV), die dafür sorgen sollen, dass gleiche Blöcke nicht das gleiche Chiffrat erzeugen. Mit einer Art Ratespiel (educated guesses) ist es auf diese Weise möglich, verschlüsselt übertragene Cookies erheblich schneller als mit Brute-Force zu ermitteln. Dafür muss sich ein Angreifer allerdings per Man-in-the-Middle-Attacke (MitM) in die Verbindung eines Opfers zum Server einklinken und im Kontext des Opfers mit dem Server kommunizieren.

Der Google-Sicherheitsanalyst Adam Langley hat dazu weitere Details veröffentlicht. Demnach gelangt ein ominöser JavaScript-Code, über den vergangene Woche noch gerätselt wurde, im Rahmen der MitM-Attacke über ein iFrame in den Browser des Opfers. Das Skript schickt dann tausende von präparierten SSL-Request an den Server und wertet die Antworten aus. Zur Automatisierung dieser Attacke hatten die beiden Sicherheitsforscher Thai Duong und Juliano Rizzo das Tool BEAST (Browser Exploit Against SSL/TLS) vorgestellt.

Das Problem lässt sich mit einer Umstellung auf den seit 2006 verabschiedeten Standard TLS 1.1 lösen, dort sind die IVs bei CBC zufällig, sodass die beschriebene Attacke nicht mehr funktioniert. Allerdings ist die Umstellung offenbar nicht so einfach zu bewerkstelligen, weil nicht alle Server und Browser den Standard unterstützen.

Chrome und Firefox benutzen nach Analysen des Sicherheitsspezialisten Thierry Zoller die Network Security Services (NSS), die nur TLS 1.0 unterstützen. Auch Windows Vista, XP, 2000 und Server 2003 sowie Server 2008 können standardmäßig noch kein TLS 1.1. Erst Windows 7 und Server 2008 R2 können TLS 1.1 nutzen. Opera 10 hingegen arbeitet sogar mit TLS-1.2-Server zusammen. Das Ändern der Browserkonfiguration nützt aber nichts, wenn der Server es nicht unterstützt.

Das in der Regel bei Apache-Webserver eingesetzte OpenSSL bietet beispielsweise noch kein TLS 1.1, dort hilft nur der Wechsel auf GnuTLS oder die Umstellung auf RC4. Die eingesetzten Ciphersuiten lassen sich in der OpenSSL-Konfigurationsdatei ssl.conf vorgeben. Eine Anleitung zum Umstellen eines IIS 7 findet man hier: Cipher Suite Mitigation for BEAST (PDF).

Google hat derweil einen Fix in die Developer-Version implementiert, der bereits im Jahre 2004 von den OpenSSL-Entwicklern vorgeschlagen wurde. Um dem Angreifer die Kontrolle über den einzuschleusenden Klartext zu erschweren, werden Pakete aufgeteilt und jedem Paket ein leeres vorangestellt.

Bislang halten sich die meisten Hersteller und Webserver-Betreiber bei der Einschätzung des Problems zurück, wohl auch, weil das Tool BEAST noch nicht öffentlich verfügbar ist.

[Update]Nach Angaben von Thierry Zoller ist das Voranstellen leerer Pakete als Schutz bereits seit längerem in OpenSSL implementiert und aktiv. Aus Kompatibilitätsgründen wird er jedoch von den meisten Anwendungen ausgeschaltet (SSL_OP_ALL oder SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS), unter anderem auch vom Apache-Webserver. [/Update] (dab)