Eine Forschungsgruppe hat einen Bericht veröffentlicht, in dem neue Angriffsmöglichkeiten auf den Diffie-Hellman-Schlüsselaustauschmechanismus beschrieben sind. Diffie-Hellman wird dafür genutzt, geheime Schlüssel auf unsicheren Kanälen zu vereinbaren.
Angreifer könnten durch Logjam zehntausende Internetdienste wie Webseiten und Mailserver angreifen und übertragene Daten lesen und manipulieren. Laut den Forschern sind etwa 8 Prozent der Top 1 Million Domains von der Sicherheitslücke betroffen. Wie die FREAK-Attacke basiert Logjam darauf, dass oft immer noch unsichere Verfahren zur TLS-Kommunikation benutzt werden, auf die ein Server „heruntergehandelt“ werden kann. Die Schwachstellen stammen aus der Zeit, in der es Exportbeschränkungen für Krypto-Software aus den USA gab, damit US-Geheimdienste nicht daran gehindert werden können, Verbindungen abzuhören und die Daten zu entschlüsseln. Damit kann ein Server – wenn er das Verfahren unterstützt – gezwungen werden, 512-bit-Schlüssel zu akzeptieren, die dem Angreifer ermöglichen, durch vorberechnete Tabellen den Geheimschlüssel zu ermitteln.
Zusätzlich gehen die Forscher davon aus, dass staatliche Angreifer wie die NSA mehr Kapazitäten als Forschungsaufbauten zur Vorberechnung der Daten haben und damit auch längere Schlüssel in Echtzeit brechen können. Das deuten auch NSA-Dokumente an, die über die Bemühungen des Dienstes berichten, VPNs zu knacken. Damals schrieben wir:
Unter welchen Bedingungen die NSA die betroffenen Verschlüsselungsprotokolle knacken kann, bleibt weiter unklar. Auch welche Implementierungen und welche Verschlüsselungsstandards betroffen sind, geht aus den Folien nicht hervor. Klar wird aus ihnen allerdings, dass die NSA sich die Handshakes, also den Austausch der Schlüssel, besonders genau anschaut und sowohl diese, als auch nicht gebrochene verschlüsselte Inhalte für später abspeichert.
Jetzt ist ein möglicher Angriff auf den Schlüsselaustausch greifbar.
Aber was tun? Ironischerweise ist der Internet Explorer der erste Browser, der einen Fix angeboten hat, andere sollen so schnell wie möglich nachziehen, indem sie Schlüssellängen kleiner 1024 bit ablehnen. Für Leute mit eigenem Server haben die Forscher eine Anleitung veröffentlicht, um die Lücke zu schließen.
Hilft u. U. https://calomel.org/firefox_ssl_validation.html weiter, wenn man dort via GUI die von Firefox akzeptieren Schlüssel entsprechend hoch einstellt?
Seit Jahren ist bekannt, dass viele Server die gleichen Primzahlen verwenden. Getan hat sich leider nur sehr wenig!
Eilig habe ich versucht, meine Server entsprechend der Anleitung abzusichern. Allerdings hab ich auf beiden Systemen (wheezy u. trusty) das Problem, dass für „SSLOpenSSLConfCmd“ leider eine zu alte openssl-Version (<1.0.2) in den Paketquellen liegt.
Kennt da jemand einen Ausweg oder muss ich openssl selbst kompilieren?
You can mitigate it right now by reconfiguring your server to remove DH
ciphers from SSLCipherSuite.
Auch, glaube ich, kannst die DH Params am ende des certs hinzufügen:
Sieht dann so aus:
—–BEGIN CERTIFICATE—–
…
—–END CERTIFICATE—–
—–BEGIN DH PARAMETERS—–
…
—–END DH PARAMETERS—–
Erstmal vielen Dank für den Tip, Mark. Hab die Parameter angehängt und den Server reloaded und restarted. Leider zeigt mir der Test immer noch die Verwendung einer 1024er-DH-Gruppe an. Ich hab nochmal geprüft, ob ich auch das richtige Zertifikat verwende, scheint aber eindeutig der Fall zu sein..
Dennoch danke.