Logjam: die neu entdeckte Sicherheitslücke und ihre Lösung

26.05.2016 | Petra Alm

Seitdem man die Sicherheitslücke Heartbleed entdeckt und beschrieben hat, tauchen regelmäßig neue Konzepte von Angriffen gegen SSL/TLS Protokolle und die damit verbundenen Verschlüsselungen auf. Dieser Artikel befasst sich mit der zuletzt definierten Sicherheitslücke Logjam, die mit schwachen Schlüsseln im Diffie-Hellman-Schlüsselaustausch (weiterhin nur DHE und DH) zu tun hat.

DH-Protokoll für Schlüsselaustausch

Das Protokoll Diffie-Hellman wird nicht für asymmetrische Verschlüsselungen verwendet, wie zum Beispiel RSA, sondern für sichere Bestimmungen von geheimen Schlüsseln oder einem geteilten Geheimnis. Dieser Funktion entspricht auch der englische Name Diffie-Hellman key exchange algorithm. Der Algorithmus wurde von Whitfield Diffie und Martin Hellman schon im Jahre 1976 ausgedacht und beruht auf einem fast unlösbaren geheimen Logarithmus.

Prinzip von Logjam

Die Sicherheitslücke Logjam stellt eigentlich den sogenannten downgrade Angriff dar, der die Sicherheit des Servers auf ein durchbrechbares Niveau abzuschwächen versucht. Dieses Prinzip ist vor allem „dank" der Sicherheitslücke FREAK bekannt, die die Unterstützung von schwachen Export-Verschlüsselungsalgorithmen auf Servern missbraucht hat. Logjam erinnert ebenfalls an die Beschränkungen der Kryptographie aus den 90ern Jahren. Ein Fachartikel, der die Sicherheitslücke Logjam und den sogenannten proof of concept beschreibt, heißt Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice. Genauso wie im Fall der Sicherheitslücke FREAK besteht das Problem in Export-DH-Verschlüsselungen mit einer Länge von 512 Bits, die man als DHE_EXPORT bezeichnet. Der Angreifer kann sie downgraden und mit einer gehörigen Ausstattung auch die Verschlüsselungsschlüssel errechnen.

Man würde denken, dass ein gut abgesicherter Server die Export-Verschlüsselungen heutzutage nicht mehr verwendet und dass für die Befürchtungen kein Grund vorliegt. Nach Experten ist jedoch der Sicherheitslücke Logjam noch ein Merkmal eigen, nämlich dass sie eine häufige Wiederholung gleicher Primzahlen nutzt und das Abhören von 1024 Bits längen DH-Verschlüsselungen ermöglicht. Den Akademikern ist es unter Universitätsbedingungen nicht gelungen, Primzahlen von 768 Bits zu durchbrechen, aber meinen, dass dank ihrer Ausstattung NSA keine Schwierigkeiten mit dem Errechnen von 1024b-Primzahlen haben sollte. Zumindest behaupten sie das in ihren eigenen, vereinfachten Forschungsergebnissen.

Laut den Akademikern verwenden 18 % der Webseiten aus der Alexa-Liste „Top One Million" für DH-Operationen eine und dieselbe häufigste Primzahl von der Länge 1024 Bits. Unter der Voraussetzung einer genügend starken Rechenleistung könnte NSA diese Webseiten passiv abhören. Aus diesem Grund wird emfpfohlen, möglichst schnell auf längere, 2048b-Schlüssel überzugehen und neue, stärkere DH-Parameter (eine Gruppe von Primzahlen) zu erstellen.

Überprüfung der Schwachstelle

Ebenso wie im Fall anderer Sicherheitslücken sollten Sie überprüfen, ob Logjam auch Ihren Server betrifft, gegebenenfalls ob Ihre Absicherung richtig funktioniert.

Ihren Server können Sie auf einem der Sicherheitslücke gewidmeten Web [2] testen und Server Test berät Sie, ob Ihr Server gefährdet ist oder nicht (mehr).

Test unseres Referenzservers BesteSSL.eu. Für Vergrößerung klicken Sie.

Der bekannteste SSLlabs-Test von Qualys hat seine Methodik ebenfalls sehr schnell geändert: wegen der neuen Sicherheitslücke Logjam setzt er die Note auf B herab. Auch der Browser Google Chrome kann allem Anschein nach die Möglichkeit des Missbrauchs von Logjam entdecken: Dem Kunden meldet er eine veraltete Kryptographie.

Prävention gegen Logjam

Das Verfahren zur Absicherung des Servers ähnelt der Vorgehensweise bei FREAK:
1. In dem ersten Schritt verbieten Sie die schwachen Export-Verschlüsselungen, falls dies durch FREAK noch nicht passiert ist (die Anleitung finden Sie unter dem Link).
2. Setzen Sie ECDHE ein (Diffie-Hellman-Protokoll, das elliptische Kurven nutzt). Moderne Browser werden es vor dem älteren DH-Protokoll bevorzugen.
3. Erstellen Sie eine neue, starke DH-Gruppe (eine Menge von Primzahlen). Viele heutige Server verwenden eine vorbestimmte Gruppe von Primzahlen, wodurch sie zu einem idealen Ziel für ein potenzielles Abhören werden. Der Administrator sollte deshalb für jeden Server oder Webseite neue und sichere (2048b+) Primzahlen erstellen.

Auf einem Server mit OpenSSL müssen Sie nur die folgende Befehlszeile eingeben, die eine unikale DH-Gruppe von 2048 Bits erstellt:

openssl dhparam -out dhparams.pem 2048

Danach aktivieren Sie auf dem Server die Verwendung der erstellten Parameter.

Für Apache ergänzen Sie in die Konfiguration (/mods-available/ssl.conf) das Folgende und führen Sie einen reload durch:

SSLOpenSSLConfCmd DHParameters "{path to dhparams.pem}"

Der Parameter SSLOpenSSLConfCmd wird von Apache 2.4.8 (und neueren Versionen) unter der Verwendung von OpenSSL 1.0.2 (und neueren) unterstützt.

Für Nginx fügen Sie in die Konfiguration das Folgende ein und starten Sie den Server neu:

ssl_dhparam {path to dhparams.pem}

Die Anleitung für andere Server wie IIS, Lighttpd, Tomcat, Sendmail, Dovecot oder OpenSSH finden Sie unter diesem Link.

Nach der Richtigstellung überprüfen Sie Ihren Server noch einmal und überzeugen Sie sich davon, dass er die schwachen DH-Verschlüsselungen nicht verwendet.

Zusammenfassung

Die neue Sicherheitslücke Logjam sollte nicht so fatale Folgen wie zum Beispiel das ein Jahr alte Heartbleed haben. Falls Sie Ihren Besuchern die höchste mögliche Sicherheit anbieten möchten, empfehlen wir Ihnen, den erwähnten Vulnerabilitätstest durchzuführen und bei einem positiven Ergebnis die Einstellung des Servers nach unserer Anleitung zu verbessern. Das Problem kann in ein paar Minuten gelöst werden.

Quellen und weitere Informationen:

1. Diffie-Hellman Schlüsselaustausch und sein Prinzip auf Wikipedia
2. der Sicherheitslücke gewidmetes Web The Logjam Attack
3. Diffie-Hellman Protokoll mit elliptischen Kurven auf Wikipedia