Original-URL des Artikels: https://www.golem.de/news/diffie-hellman-unsinnige-krypto-parameter-1403-104970.html    Veröffentlicht: 06.03.2014 19:01    Kurz-URL: https://glm.io/104970

Diffie-Hellman

Unsinnige Krypto-Parameter

Ein kurzer Schlüsselaustausch bringt Chrome zum Absturz, andere Browser akzeptieren völlig unsinnige Parameter für einen Diffie-Hellman-Schlüsselaustausch. Im Zusammenhang mit den jüngst gefundenen TLS-Problemen könnte das ein Sicherheitsrisiko sein.

Wer in den vergangenen Tagen versucht hat, die Webseite https://demo.cmrg.net/ mit einer aktuellen Version des Chrome-Browsers oder dessen freiem Pendant Chromium aufzurufen, hat feststellen müssen, dass dies den Browser zum Absturz gebracht hat. Darauf wurde am Dienstag über die Mailingliste oss-security hingewiesen. Die Nachricht verbreitete sich schnell und verschaffte der Testseite große Aufmerksamkeit.

Chrome stürzt ab

Doch die Seite sollte eigentlich nicht dazu dienen, Abstürze in Browsern zu verursachen. Sie wurde laut einem Thread bei LWN.net bereits im November 2013 aufgesetzt und diente dazu, die Auswirkungen extrem kurzer Parameter bei einem Schlüsselaustausch mit Diffie-Hellman zu testen. Diffie-Hellman kann im TLS-Protokoll dazu genutzt werden, eine Verbindung mit Perfect Forward Secrecy aufzubauen.

Für einen Schlüsselaustausch mit Diffie-Hellman benötigt ein Server zwei Parameter, die er bei einem versuchten Verbindungsaufbau dem Client mitteilt: eine große Primzahl und einen sogenannten Generator. Von der Größe der Primzahl hängt die Sicherheit des Verfahrens ab. Üblich sind heutzutage meistens 1.024 Bit, was jedoch nicht mehr als sicher gilt. Vor allem der Apache-Webserver hat aber dafür gesorgt, dass ein derartig kurzer Schlüsselaustausch nach wie vor weit verbreitet ist. Erst in der jüngsten Version 2.4.7 verfügt Apache über die Möglichkeit, einen Schlüsselaustausch mit größeren Primzahlen durchzuführen.

Die oben erwähnte Testseite versucht, eine Verbindung mit viel zu kurzen 16 Bit aufzubauen und entdeckte dabei offenbar einen gravierenden Bug im Code von Chromium. Wir haben uns daraufhin angesehen, wie andere Browser mit kurzen oder unsinnigen Schlüsselaustausch-Parametern umgehen.

Mozilla Firefox lehnt einen Verbindungsaufbau mit sehr kurzen Primzahlen von 256 Bit und kleiner ab, Verbindungen mit 512 und 768 Bit waren jedoch möglich. Auch das ist aus heutiger Sicht sehr unsicher. Ähnlich verhält sich auch Chromium, wenn ein inzwischen verfügbarer Patch verwendet wird, der den Absturz verhindert. Beide Browser nutzen die NSS-Bibliothek, die Verbindungen mit sehr kurzen Primzahlen abblockt.

Internet Explorer: mangelhafter Support für Diffie-Hellman

Im Internet Explorer gestaltete sich ein Test etwas schwieriger, denn unter normalen Umständen unterstützt der Microsoft-Browser keinen Diffie-Hellman-Schlüsselaustausch. Er ermöglicht diesen nur, wenn ein Serverzertifikat mit einem DSA-Schlüssel eingesetzt wird, und dieser darf auch lediglich eine Länge von 1.024 Bit haben. DSA-Schlüssel für TLS-Verbindungen sind extrem ungewöhnlich, viele gängige Zertifizierungsstellen stellen nur für RSA-Schlüssel Zertifikate aus, für 1.024 Bit Länge heutzutage eigentlich generell nicht mehr. Wir stießen bei unserem Test aber darauf, dass man bei CAcert, einer freien Zertifizierungsstelle, die jedoch in den gängigen Browsern nicht integriert ist, nach wie vor DSA-Zertifikate mit 1.024 Bit ausstellen kann.

Im Internet Explorer wurden ähnlich wie bei Firefox und Chromium Verbindungen erst ab 512 Bit erlaubt. Interessanterweise verweigerte der Microsoft-Browser jedoch auch Verbindungen mit 2.048 und 4.096 Bit. Zu viel Sicherheit darf es bei Microsoft also auch nicht sein. Allerdings: In der Praxis ist das weitgehend irrelevant, da der Internet Explorer mit gängigen RSA-Zertifikaten nur einen Schlüsselaustausch über elliptische Kurven zulässt.

Opera verbindet erst ab 1.024 Bit

Opera zeigte sich deutlich strenger als die anderen Browser, was kurze Primzahlen angeht. Bei Verbindungen unter 1.024 Bit zeigt Opera eine Warnung und fragt den Nutzer, ob er sich wirklich verbinden möchte. Empfehlenswert wäre es, wenn andere Browser hier nachziehen. Legitime Gründe, einen Schlüsselaustausch mit weniger als 1.024 Bit durchzuführen, gibt es keine.

Interessant war das Verhalten von Safari unter Mac OS und von Konqueror unter Linux. Beide Browser akzeptierten praktisch alles an unsinnigen Parametern. Selbst mit extrem kleinen Primzahlen wie 17 akzeptierten die Browser einen Verbindungsaufbau. Sogar mit 15 als "Primzahl" ließ sich eine Verbindung aufbauen.

Kein Browser prüft Primzahlen

Ob es sich bei der übertragenen Primzahl tatsächlich um eine solche handelt, prüfte in unseren Tests kein einziger Browser. Eine Testverbindung mit 1.024 Bit mit einer Nichtprimzahl als übertragenem Parameter war mit allen Browsern möglich. Der Grund hierfür dürfte sein, dass die Prüfung, ob eine Zahl eine Primzahl ist, nicht ganz trivial ist.

Um Primzahlen zu testen, nutzt man üblicherweise den sogenannten Miller-Rabin-Test. Dieser liefert zwar keinen exakten mathematischen Beweis, ob eine große Zahl eine Primzahl ist, sondern nur eine sehr hohe Wahrscheinlichkeit, doch in der Praxis reicht dies bereits. Bei 1.024 Bit ist ein Miller-Rabin-Test noch sehr schnell möglich, bei 4.096 Bit können aber auf langsamen CPUs hierfür bereits Sekunden vergehen. Für einen HTTPS-Verbindungsaufbau eine oft nicht akzeptable Verzögerung.

Triple-Handshake-Angriff kann falsche Primzahlen missbrauchen

Zunächst könnte man annehmen, dass es keine Rolle spielt, wenn Browser unsichere Parameter für einen Schlüsselaustausch akzeptieren, denn im Normalfall kommen solche nicht vor. Denkbar wäre lediglich, dass ein Server böswillig unsinnige Parameter sendet. Doch das würde bedeuten, dass der Server nicht vertrauenswürdig ist. Die übertragenen Inhalte sind dann sowieso ebenso nicht als vertraulich anzusehen - der Server könnte sie ja auch ganz unverschlüsselt an Dritte weitergeben.

Doch im Zusammenhang mit Clientzertifikaten können die unsicheren Parameter zum Problem werden. Vor wenigen Tagen stellte ein Forscherteam einige Angriffsmöglichkeiten gegen das TLS-Protokoll vor, in denen ein bösartiger Server sich gegenüber einem weiteren Server mit dem Zertifikat eines Nutzers ausgeben kann. Die Autoren des sogenannten Triple-Handshake-Angriffs erwähnen dabei auch eine Variante, die mit unsicheren Diffie-Hellman-Parametern arbeitet. Die meisten Szenarien sind hiervon nicht betroffen, da Clientzertifikate nur wenig verbreitet sind.

Feste Parameter für Diffie-Hellman vorgeschlagen

Die Autoren schlagen vor, dass man für TLS feste Parameter für den Diffie-Hellman-Schlüsselaustausch standardisieren sollte. Dann könnte ein Server schnell prüfen, ob es sich um die bekannten Parameter handelt - und wäre sicher, dass es echte Primzahlen sind. Ob unsichere Parameter auch in anderen Szenarien zum Problem werden, wird erst weitere Forschung zeigen.

Grundsätzlich zeigen die Absturzprobleme von Chromium, dass bislang selten getestet wird, wie Software auf unsinnige Parameter in kryptographischen Protokollen reagiert. Ähnliche Tests für andere Verfahren könnten hier noch weitere Probleme aufdecken. Die Tests, die wir für die Recherche durchgeführt haben, sind unter der URL https://dh.tlsfun.de/ abrufbar.  (hab)


Verwandte Artikel:
Verschlüsselung: Strato bietet Perfect Forward Secrecy   
(11.02.2014, https://glm.io/104504 )
ROBOT-Angriff: Arbeitsagentur nutzt uralte Cisco-Geräte   
(09.03.2018, https://glm.io/133258 )
Trustico/Digicert: Chaos um 23.000 Zertifikate und private Schlüssel   
(01.03.2018, https://glm.io/133077 )
Crypto-Messenger: Signal-Desktop-Client wechselt von Chrome auf Electron   
(01.11.2017, https://glm.io/130912 )
Verschlüsselung: Niemand hat die Absicht, TLS zu knacken   
(13.10.2017, https://glm.io/130594 )

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