Translated message

A translation of this page exists in English.

Logjam: TLS-Sicherheitslücken (CVE-2015-4000)

Aktualisiert -

Red Hat Product Security wurde auf verschiedene Probleme mit TLS-Verbindungen hingewiesen, die das Diffie-Hellman (DH) Schlüsselaustauschprotokoll verwenden.

Hintergrundinformationen

TLS-Verbindungen, die das Diffie-Hellman-Protokoll zum Schlüsselaustausch verwenden, sind gefährdet durch einen möglichen Man-in-the-Middle-Angriff, bei dem für betroffene TLS-Verbindungen ein Rückfall auf 512-Bit-Kryptografie der Export-Klasse erzwungen wird. Der Angriff betrifft Server, die das DHE_EXPORT-Verschlüsselungsverfahren unterstützen. Bei diesem Angriff erfolgt bereits im Vorfeld ein großer Teil der Berechnung der 512-Bit-Primzahlen, die in zwei weit verbreiteten, schwachen Diffie-Hellman-Parametern – nämlich in Apaches httpd Versionen 2.1.5 bis 2.4.7 und in allen Versionen von OpenSSL – enthalten sind.

Die Logjam-Studie erläutert die folgenden Probleme im Zusammenhang mit schwachen DH-Schlüsseln:

  1. Die Verwendung des DHE_EXPORT-Verschlüsselungsverfahrens im TLS-Protokoll oder DHE-Schlüssel mit Schlüsselstärke der Export-Klasse: Diese Schlüssel sind 512 Bits lang und können mit genug Rechenleistung und etwas Geduld gebrochen werden. Dies stellt insbesondere bei Perfect Forward Secrecy (auch Folgenlosigkeit genannt) ein Problem dar, da ein Angreifer den Datenverkehr aufzeichnen und später entschlüsseln kann.

  2. Die Verwendung von vorab berechneten Primzahlen, die in bestimmten, weit verbreiteten Paketen enthalten sind, zum Beispiel in Apache httpd und sshd: Diese Schwachstelle erlaubt es einem Angreifer, solche Primzahlen einmal zu berechnen und damit anschließend jeglichen Datenverkehr zu entschlüsseln, der diese Primzahlen zur Herstellung einer TLS-Verbindung verwendet.

  3. Eine Schwachstelle im TLS-Protokoll, die zu einem Rückfall von DHE auf DHE_EXPORT führen kann: Dieses Problem ist gekennzeichnet als CVE-2015-4000.

Auswirkungen

Die oben genannten Schwachstellen ermöglichen die folgenden Angriffsszenarien:

  1. Offline-Entschlüsselung schwacher DHE-Verbindungen
    Dieser Angriff erfordert, dass der Server standardmäßig den Diffie-Hellman-Schlüsselaustausch mit 512-Bit-Parametern verwendet. Dies ermöglicht es einem passiven Angreifer auf dem Netzwerk, der die Kommunikation zwischen einem Client und einem Server abfängt, diese Kommunikation zu entschlüsseln.

  2. Rückfall auf DHE_EXPORT und Offline-Entschlüsselung der TLS-False-Start-Erweiterung
    Dieser Angriff erfordert, dass ein Server das DHE_EXPORT-Verschlüsselungsverfahren unterstützt oder 512-Bit-Parameter in DHE-Verschlüsselungsverfahren (nicht der Export-Klasse) verwendet. Der Client muss die TLS-False-Start-Erweiterung verwenden. Unter diesen Umständen kann ein Angreifer die Kommunikation zwischen einem Client und einem Server aufzeichnen und die Kommunikation entschlüsseln.

  3. Rückfall auf DHE_EXPORT und Server-Identitätsmanipulation durch Man-in-the-Middle-Angriff
    Dieser Angriff ähnelt dem vorherigen Angriff, erfordert jedoch nicht, dass die TLS-False-Start-Erweiterung aktiviert ist. Stattdessen ist der Angreifer darauf angewiesen, dass der Client lange genug wartet, bis der Handshake abgeschlossen ist. Dies kann mehrere Minuten in Anspruch nehmen, da der Angreifer während des Handshake-Vorgangs den Verbindungsschlüssel berechnen muss.

Lösung

SSL/TLS-Server

Beim Man-in-the-Middle-Angriff versucht der Angreifer, unter Verwendung des DHE_EXPORT-Verschlüsselungsverfahrens anstelle des Clients mit dem Server zu verbinden. Möglich ist dies durch einen Entwurfsfehler des TLS-Protokolls in der Funktionsweise von DHE- und DHE_EXPORT-Verschlüsselungsverfahren. Dieser Protokollfehler kann für einen aktiven Man-in-the-Middle-Angriff ausgenutzt werden, sofern der Server DHE_EXPORT-Verschlüsselungsverfahren unterstützt.

Dieses Problem betrifft nicht die aktuellen Versionen der openssl Pakete, die in Red Hat Enterprise Linux 6 und 7 enthalten sind, da sie nicht die DHE_EXPORT-Verschlüsselungsverfahren oder jegliche andere Verschlüsselungsverfahren der Exportklasse in den DEFAULT-Listen der Verschlüsselungsverfahren enthalten. (Applikationen, die das DEFAULT-Verschlüsselungsverfahren nutzen, werden keine Verschlüsselungsverfahren der Exportklasse verwenden. Allerdings kann eine applikationsspezifische Konfiguration die Verwendung von Verschlüsselungsverfahren der Exportklasse wieder aktivieren.) Bitte beachten Sie, dass dies nur der Fall ist, wenn openssl von einem Netzwerkserver verwendet wird. Informationen über Client-Probleme finden Sie unten.

Die openssl-Pakete in Red Hat Enterprise Linux 7 schlossen bereits seit der ersten Release beim Einsatz als Server die Verschlüsselungsverfahren der Exportklasse von den DEFAULT-Listen aus. In Red Hat Enterprise Linux 6 wurde diese Änderung im Advisory RHBA-2014:1525 implementiert, das als Teil von Red Hat Enterprise Linux 6.6 veröffentlicht wurde.

Red Hat Enterprise Linux 5 unterstützt das Verschlüsselungsverfahren der Exportklasse in seiner Liste der standardmäßigen Verschlüsselungsverfahren. Red Hat beabsichtigt nicht, die Liste der standardmäßige Verschlüsselungsverfahren in Red Hat Enterprise Linux 5 zu ändern, da die Auswirkungen dieser CVE als moderat klassifiziert wurden. Weitere Informationen darüber, welche Sicherheits-Advisorys in der Produktionsphase 3 implementiert werden, finden Sie auf der Seite zum Red Hat Enterprise Linux Lebenszyklus.

SSL/TLS-Clients

Da Clients keine Kontrolle über das Verschlüsselungsverfahren des SSL/TLS-Servers haben, besteht ihre einzige Abwehr darin, kleine Primzahlen im DHE-Handshake abzulehnen. Werden größere Primzahlen vorausgesetzt, kann dies die oben erwähnten Rückfallangriffe verhindern.

Upstream-OpenSSL geht die verbleibenden zwei Probleme an, indem die Mindestgröße von DH-Parametern, die ein Client akzeptieren kann, auf 768 Bits erhöht wird. Dadurch wird der Client selbst nach einem erzwungenen Rückfall der Verbindung durch einen Man-in-the-Middle-Angreifer die Verbindung ablehnen, wenn weniger als 768 Bits verwendet werden, was als leicht zu brechen gilt.

Derzeit akzeptieren alle Versionen der NSS-Pakete, die in Red Hat Enterprise Linux enthalten sind, 512-Bit DHE-Parameter. Der folgende Upstream-Fehlerbericht und der zugehörige Commit geben an, das Problem gelöst zu haben, und heben die Grenze auf 1023 Bits an:

Diese Änderung wird derzeit von Red Hat Product Security untersucht und wird gegebenenfalls in die relevanten NSS-Pakete in Red Hat Enterprise Linux eingearbeitet.

Openswan/Libreswan

Der Logjam-Rückfallangriff auf TLS betrifft nicht IKE in Openswan und Libreswan. Der pluto-Daemon, der in den Paketen openswan und libreswan enthalten ist, stellt die IKEv1- und IKEv2-Protokolle bereit, um IPsec-VPN-Tunnel zu generieren, der Logjam-Angriff zielt dagegen auf TLS ab. Zudem nutzen Openswan und Libreswan beide standardmäßige DH-Gruppen über MODP1024 und unterstützen nicht MODP768 und darunter.

JBoss-Produkte

Informationen über Gegenmaßnahmen zur Logjam-Sicherheitslücke in betroffenen JBoss-Produkten finden Sie unter Logjam: TLS vulnerabilities (CVE-2015-4000) for JBoss products

Comments