Technologie

Yet another TLS-Katastrophe – Logjam-Angriff auf Diffie-Hellman-Schlüsselaustausch

Log jam in freier Wildbahn

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.

Wir finanzieren uns fast vollständig aus Spenden von Leserinnen und Lesern. Unterstütze unsere Arbeit mit einer Spende oder einem Dauerauftrag.

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.

Weitersagen und Unterstützen. Danke!
5 Kommentare
  1. 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?

    1. 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—–

      1. 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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.