Original-URL des Artikels: https://www.golem.de/news/logjam-angriff-schwaeche-im-tls-verfahren-gefaehrdet-zehtausende-webseiten-1505-114161.html    Veröffentlicht: 20.05.2015 14:35    Kurz-URL: https://glm.io/114161

Logjam-Angriff

Schwäche im TLS-Verfahren gefährdet Zehntausende Webseiten

Verschlüsselte Verbindungen können durch eine Schwäche im TLS-Verfahren in vielen Fällen auf einen unsicheren Diffie-Hellman-Schlüsselaustausch mit 512 Bit reduziert werden. Forscher vermuten, dass eine Variante dieses Angriffs für das NSA-Programm Turmoil verantwortlich sein könnte.

Ein Team von Kryptographen hat sich in einer ausführlichen Analyse mit dem Diffie-Hellman-Schlüsselaustausch in TLS und anderen Protokollen beschäftigt. Es gelang ihnen dabei, mittels eines Man-in-the-Middle-Angriffs HTTPS-Verbindungen in einen unsicheren Export-Modus zu zwingen, der angreifbar ist. Damit könnte ein Angreifer etwa Javascript-Code in die Verbindung einfügen oder den Datenverkehr mitlesen. Betroffen sind etwa acht Prozent der wichtigsten Webseiten. Diesen Angriff bezeichnen sie als Logjam, benannt nach dem diskreten Logarithmus, der für die Sicherheit des Diffie-Hellman-Verfahrens entscheidend ist. Doch das ist nur eines von einer ganzen Reihe von Problemen. Die Autoren vermuten, dass ein ähnlicher Angriff von der NSA verwendet wird.

Forward Secrecy durch Diffie-Hellman-Schlüsselaustausch

Der klassische Diffie-Hellman-Schlüsselaustausch ist ein relativ altes Verfahren, mit dem man Forward Secrecy bei verschlüsselten Verbindungen gewährleisten kann. Dabei müssen sich die beiden Kommunikationspartner vorher auf eine sogenannte Gruppe und einen Generator einigen - beim klassischen Diffie-Hellman-Verfahren ist die Gruppe schlicht eine große Primzahl. Die Größe dieser Gruppe ist entscheidend für die Sicherheit des Verfahrens. 512 Bit gelten als extrem unsicher, werden aber nach wie vor teilweise genutzt, 1.024 Bit gelten als problematisch und 2.048 Bit sind nach aktuellem Kenntnisstand sicher.

In den 90er Jahren gab es in den USA gesetzliche Beschränkungen für den Export von Kryptographie. Um dem gerecht zu werden, wurde in SSL (dem Vorgänger von TLS) ein Export-Modus für den Diffie-Hellman-Schlüsselaustausch eingeführt, der die Gruppenlänge auf 512 Bit begrenzt. Dieser veraltete Modus fällt nun vielen Implementierungen auf die Füße. Zwar wird er normalerweise nicht genutzt, manche Server unterstützen ihn aber noch aus Kompatibilitätsgründen. Unter den Millionen beliebtesten Seiten laut der Statistik von Alexa unterstützen acht Prozent noch den unsicheren Export-Modus.

An sich wäre das kein Problem, denn kein normaler Browser wählt diesen Modus aus. Doch die Autoren fanden eine Schwäche im TLS-Handshake. Dieser läuft so ab, dass der Client dem Server eine Liste von Algorithmen schickt, aus denen der Server einen auswählen kann. Was nun zum Problem wird: An dieser Stelle ist der Handshake noch nicht signiert. Ein aktiver Angreifer kann also einen Handshake des Nutzers ändern und dem Server statt des gewöhnlichen Diffie-Hellman-Schlüsselaustauschs einen unsicheren Export-Schlüsselaustausch anbieten. Der Server wiederum antwortet mit einer unsicheren 512-Bit-Gruppe.

Die Krux dabei: Die meisten Clients akzeptieren auch im normalen Modus 512-Bit-Gruppen. Insofern kann der Angreifer die Serverantwort ändern und dem Client einen normalen Diffie-Hellman-Schlüsselaustausch mit 512 Bit vorgaukeln. Eine Analyse von Golem.de hat im vergangenen Jahr ergeben, dass einige Browser sogar komplett unsichere Gruppen von wenigen Bits akzeptieren.

Um diesen Angriff durchzuführen, ist es notwendig, dass der Angreifer den Schlüsselaustausch in Echtzeit angreifen kann. Das wäre selbst mit den besten Algorithmen und großen Spezialcomputern eine extreme Herausforderung. Um den Diffie-Hellman-Schlüsselaustausch anzugreifen, muss ein diskreter Logarithmus berechnet werden, das beste hierfür bekannte Verfahren ist das sogenannte Zahlkörpersieb.

Vorberechnungen ermöglichen Angriff in Minuten

Doch das Zahlkörpersieb erlaubt ein sehr gezieltes Tuning des Angriffs. Wenn die verwendete Gruppe vorher bekannt ist, kann ein Großteil der Berechnungen vorab durchgeführt werden. Die verwendete Gruppe ist kein Geheimnis und ein Server setzt üblicherweise für alle Verbindungen die gleichen Gruppen ein. Vielfach sind die Gruppen sogar bereits Teil der Software. Unter den Servern, die den Export-Modus unterstützen, nutzen 93 Prozent die gleiche Gruppe.

Mittels eines Clusters von mehreren Tausend PCs gelang es den Forschern, innerhalb von einer Woche Vorberechnungen für eine bestimmte Gruppe durchzuführen. Anschließend ließ sich der aktive Angriff auf einem System mit vier Intel-Xeon-E7-Prozessoren mit jeweils sechs Cores in durchschnittlich 90 Sekunden durchführen. Dabei variierte die Geschwindigkeit jedoch deutlich, zwischen 36 und 260 Sekunden. Mit Spezialhardware und weiteren Optimierungen ließe sich dieser Angriff, so spekulieren die Forscher, vermutlich auf unter eine Minute reduzieren.

Für einen aktiven Angriff ist das nach wie vor relativ viel. Doch einige Eigenschaften von Browsern erleichtern den Angriff unter Umständen. TLS unterstützt ein Feature namens Warning Alerts. Diese Pakete werden von Browsern zwar ignoriert, jedoch führen sie dazu, dass der Timeout-Counter zurückgesetzt wird. In Firefox lässt sich damit ein Handshake beliebig lange verzögern, in anderen Browsern wird die Verbindung nach einer Minute abgebrochen. Um einen Angriff auf eine HTTPS-Verbindung unbemerkt durchzuführen, könnte der Angreifer nicht die eigentliche Seite, sondern stattdessen eine externe Ressource, etwa einen Tracking- oder Werbe-Javascript-Code, angreifen. Sein Fehlen würde beim Seitenaufbau nicht direkt auffallen.

Um den Angriff zu vereiteln, schlagen die Autoren vor, dass Browser künftig den Schlüsselaustausch mit Gruppen kleiner als 1.024 Bit komplett verbieten. Chrome-Entwickler Adam Langley hat bereits angekündigt, dies spätestens in der Version 45 von Chrome umzusetzen. Ohne Probleme wird dies nicht verlaufen: Da nach wie vor einige Seiten ausschließlich sehr kurze Diffie-Hellman-Gruppen einsetzen, werden manche Seiten danach nicht mehr erreichbar sein. Die Webseite zum Logjam-Angriff enthält einen Test, der prüft, ob Browser 512-Bit-Gruppen akzeptieren.

Der Angriff erinnert in vielen Punkten an den Freak-Angriff, der im März veröffentlicht wurde. Auch bei Freak konnte ein Angreifer eine Verbindung in einen alten Export-Modus zwingen. Allerdings basierte Freak auf Softwarefehlern in OpenSSL und in Microsofts TLS-Implementierung. Logjam jedoch ist ein Fehler direkt im TLS-Protokoll.

Unsichere Primzahlen und falsche Parameter

Neben dem Logjam-Angriff fanden die Autoren eine Reihe von weiteren Problemen. Insgesamt gibt es 2.361 Server mit gültigen Zertifikaten, die im normalen Modus eine 512-Bit-Gruppe für Diffie-Hellman nutzen. Hier ist unter Umständen überhaupt kein aktiver Angriff notwendig, ein passives Lauschen reicht bereits, der Datenverkehr kann später entschlüsselt werden. Allerdings ist nicht gewährleistet, dass Verbindungen auch diesen Algorithmus nutzen. Das hängt von den Präferenzen des Clients und von der Reihenfolge ab, in der der Server die Algorithmen anbietet.

Viele Server nutzen keine sicheren Primzahlen

Die Primzahlen, die als Gruppe für den Diffie-Hellman-Austausch zum Einsatz kommen, müssen eine bestimmte Eigenschaft haben, damit der Schlüsselaustausch sicher ist. Diese sicheren Primzahlen kann man leicht prüfen. Bei einer Primzahl p sollte der Wert (p-1)/2 ebenfalls eine Primzahl sein. Die Autoren des Logjam-Papers fanden erstaunlich viele dieser unsicheren Primzahlen. Unter 70.000 unterschiedlichen Primzahl-Gruppen, die bei einem Scan von HTTPS-Servern gefunden wurden, erfüllten 4.800 nicht die erforderlichen Sicherheitseigenschaften. Neun Gruppen waren überhaupt keine Primzahl. In dem Fall ist nicht einmal gewährleistet, dass der Diffie-Hellman-Algorithmus überhaupt funktioniert. Mittels eines Angriffs, der erstmals 1996 von Paul van Orschot und Michael Wiener vorgestellt wurde, lässt sich bei unsicheren Primzahlen der Schlüsselaustausch manchmal angreifen, das hängt aber von weiteren Details ab.

Ein weiterer Fund der Autoren ist eher eine Kuriosität: Der Digital Signature Algorithm (DSA) spezifiziert Parameter, die man ebenfalls für einen Diffie-Hellman-Schlüsselaustausch verwenden kann. Einige Server brachten hier aber die Werte durcheinander und nutzten die sogenannte Gruppenordnung des DSA-Algorithmus als Generator. Dadurch wird die Sicherheit des Schlüsselaustauschs deutlich gesenkt. Den Grund für diesen Fehler vermuten die Autoren in der Codierung der jeweiligen Parameter. Liest man die DSA-Parameter direkt in der Reihenfolge, wie die Speicherung der Diffie-Hellman-Parameter spezifiziert ist, erhält man diesen Fehler.

Knackt die NSA 1.024 Bit?

Zuletzt machen sich die Autoren einige Gedanken über den Diffie-Hellman-Austausch mit größeren, aber dennoch problematischen Gruppen mit 768 oder 1.024 Bit. Ein Angriff auf 768 Bit ist sehr aufwendig, wäre aber noch im Bereich dessen, was ein gut finanziertes Forschungsinstitut durchführen könnte. Ein Angriff auf 1.024 Bit ist im Bereich des Möglichen, die Kosten lägen aber bei mehreren Hundert Millionen Dollar.

Die Schätzungen für einen Angriff auf 1.024 Bit gestalteten sich als relativ schwierig. Die bestehende Forschung dazu ist laut den Autoren in vielen Fällen ungenau, insofern handelt es sich auch nur um relativ ungenaue Werte. Für einige Schritte des Angriffs gibt es die Möglichkeit, diese mit ASIC-Spezialhardware deutlich zu beschleunigen. Für einen wichtigen Schritt des Zahlkörpersiebs existieren jedoch bislang keine Forschungsarbeiten, wie dieser auf Spezialchips umgesetzt werden könnte.

Verbindungen zum NSA-Programm TURMOIL?

Aufgrund des Milliardenbudgets der NSA gehen die Autoren davon aus, dass ein derartiger Angriff für den US-Geheimdienst im Bereich des Möglichen liegt. Ein Dokument aus den Snowden-Veröffentlichungen, das der Spiegel im vergangenen Jahr veröffentlicht hat, deutet darauf hin, dass die NSA in der Lage ist, bestimmte IPSEC-Verbindungen zu entschlüsseln. Darin ist ein Programm namens TURMOIL beschrieben. Die Autoren des Logjam-Angriffs vermuten, dass TURMOIL auf einem Angriff auf Diffie-Hellman basiert.

Bei IPSEC werden - anders als bei TLS - festgelegte Gruppen verwendet. Eine Vorberechnung wäre somit in jedem Fall möglich. Die große Mehrzahl der im Internet erreichbaren IPSEC-Endpunkte nutzt eine 1.024-Bit-Gruppe namens Oakley Group 2, die im RFC 2409 spezifiziert wurde.

Auch für SSH könnte Oakley Group 2 ein Problem darstellen. Fast alle Server unterstützen diese Gruppe, sie wird aber nicht zwangsweise auch genutzt. Mit einer aktuellen OpenSSH-Version nutzte aber immerhin noch ein Viertel der Server diese problematische Gruppe.

Alte Apache-Versionen sind ein Problem

Während die Abschaffung von Gruppen kleiner als 1.024 Bit wohl relativ praktikabel ist, gestaltet sich das bei 1.024 Bit schwieriger. Sehr viele Webserver nutzen noch derartige Gruppen. Apache unterstützt erst seit der Version 2.4.7 größere Gruppen. Viele Server nutzen allerdings noch Apache 2.2, da ältere Versionen von Debian und Red Hat nur diesen alten Versionszweig ausliefern. Ältere Java-Clients unterstützen ebenfalls nur 1.024 Bit, erst Java 8 unterstützt größere Gruppen. OpenSSH hat die unsicheren Gruppen erst in der Version 6.5 deaktiviert, die Anfang 2014 veröffentlicht wurde.

Nicht betroffen von all diesen Problemen sind Schlüsselaustauschverfahren auf Basis elliptischer Kurven. Doch auch dafür möchten die Autoren von Logjam keine uneingeschränkte Empfehlung geben: Die weit verbreiteten elliptischen Kurven wurden von der NSA generiert. Zwar gibt es keine bekannten Angriffe, das Verfahren, mit dem diese Kurven generiert wurden, lässt aber einige Fragen offen.

Neben einigen Empfehlungen für Serverkonfigurationen gibt es auch eine politische Empfehlung der Autoren: Man solle sich davor hüten, Kryptographie bewusst unsicher zu gestalten. Damit verweisen sie indirekt auf jüngste politische Debatten, in denen Politiker und Sicherheitsbehörden Hintertüren in Verschlüsselungsverfahren gefordert hatten. Ähnlich wie Freak sei der Angriff eine Warnung vor den Langzeiteffekten von bewusst unsicher gemachter Kryptographie.  (hab)


Verwandte Artikel:
Verschlüsselung: Github testet Abschaltung alter Krypto   
(09.02.2018, https://glm.io/132684 )
Cloudflare: TLS-Verbindungen ohne Schlüssel sollen Banken schützen   
(19.09.2014, https://glm.io/109351 )
Kryptographie: Schnellerer Algorithmus für das diskrete Logarithmusproblem   
(17.05.2014, https://glm.io/106547 )
ROBOT-Angriff: Arbeitsagentur nutzt uralte Cisco-Geräte   
(09.03.2018, https://glm.io/133258 )
Librem 5: Purism-Smartphone bekommt Smartcard für Verschlüsselung   
(09.03.2018, https://glm.io/133248 )

© 1997–2019 Golem.de, https://www.golem.de/