Translated message

A translation of this page exists in English.

SWEET32: Angriffe gegen TLS-Verschlüsselungsalgorithmen mit 64-Bit-Blockgröße aufgrund von Geburtstagsparadoxon (CVE-2016-2183)

Aktualisiert -

Überblick

Red Hat Product Security wurde auf ein Problem mit Blockchiffren innerhalb der SSL/TLS-Protokolle hingewiesen, das in bestimmten Konfigurationen einen Kollisionsangriff ermöglicht. Dieses Problem wurde mit dem Schweregrad Mäßig klassifiziert und wird unter CVE-2016-2183 geführt. Dieses Problem erfordert derzeit keinerlei Aktualisierungen oder Maßnahmen für Benutzer von Red Hat Produkten. Im Abschnitt Lösung finden Sie weitere Details.

Hintergrund

Alte Blockchiffren mit Blockgrößen von 64 Bits sind anfällig für einen praktischen Kollisionsangriff, wenn sie in CBC-Modus ausgeführt werden. Alle Versionen der SSL/TLS-Protokolle, die Chiffren mit 3DES als symmetrischen Verschlüsselungsalgorithmus verwenden, sind betroffen (zum Beispiel ECDHE-RSA-DES-CBC3-SHA). In den Versionen von OpenSSL, die in Red Hat Enterprise Linux 6 und 7 enthalten sind, rangieren DES-basierte Verschlüsselungsalgorithmen unter jenen, die AES-128 (mit PFS-Chiffren) und AES-256 unterstützen. Das bedeutet, dass DES-Chiffren nur dann gewählt werden, wenn der Server AES-128 und AES-256 ausdrücklich deaktiviert. In den Versionen von OpenSSL, die in Red Hat Enterprise Linux 5 enthalten sind, rangieren DES-basierte Chiffren unter AES-256, jedoch über AES-128. In diesem Fall wird DES nur dann gewählt, wenn der Server AES-256-basierte Chiffren ausdrücklich deaktiviert.

Die Sicherheit einer Blockchiffre hängt von der Schlüssellänge (k) ab. Daher ist der beste Angriff gegen eine Blockchiffre eine erschöpfende Schlüsselsuche, die eine Komplexität hat von 2k. Wenn Blockchiffren jedoch zur Verschlüsselung von großen Datenmengen verwendet werden mithilfe von Verschlüsselungsmodi wie CBC, spielt die Blockgröße (n) ebenfalls eine große Rolle für die Sicherheit.

Wenn bei der Verschlüsselung der CBC-Modus verwendet wird, tritt nach 2n/2 Datenblöcken, die mit demselben Algorithmus verschlüsselt wurden, aufgrund des sogenannten Geburtstagsparadoxons mit hoher Wahrscheinlichkeit eine Kollision von zwei Chiffreblöcken auf. Eine Kollision in der Ausgabe bedeutet, dass die Eingabe identisch ist. Diese Daten können in Kombination mit bestimmten Bedingungen (unten erläutert) dazu verwendet werden, den Klartext aus den verschlüsselten Daten zu erhalten.

Praktische Anwendbarkeit des Angriffs

  1. DES/3DES ist der einzige in SSL/TLS verwendete Verschlüsselungsalgorithmus, der eine Blockgröße von 64 Bits hat. Wie bereits im Abschnitt »Hintergrund« erwähnt, werden Verschlüsselungsalgorithmen mit 3DES niedriger priorisiert als andere Verschlüsselungsalgorithmen (z.B. AES-128).

  2. Um den Angriff auf 64-Bit-Blockchiffren durchzuführen, müssen mindestens 32 GB Daten abgefangen werden. Im Fall von SSL/TLS bedeutet dies von einer einzigen SSL/TLS-Sitzung. (Für alle neuen Sitzungen verhandelt SSL/TLS die symmetrischen Schlüssel neu). Deshalb könnten lang andauernde https-Verbindungen gefährdet sein.

  3. In vielen Kontexten ist es für einen praktikablen Angriff nicht ausreichend, das XOR zwischen zwei Blöcken von Klartext aufzuspüren. Allerdings ist ein Angriff möglich, wenn folgende Bedingungen erfüllt sind:

    • Ein festgelegtes Geheimnis wird wiederholt gesendet;

    • Ein Teil des Klartextes ist bekannt.

  4. Der in der Studie dargelegte Machbarkeitsnachweis geht davon aus, dass ein Authentifizierungs-Token zwischen dem Server und dem Client für sämtliche Kommunikation ausgetauscht wird (Token könnte ein Cookie mit den Berechtigungsnachweisen für eine einfache Authentifizierung sein). Der Angreifer führt dann ein bösartiges JavaScript in der Quelle der Website aus, die angegriffen wird. Ein BEAST-Angriff kann danach verwendet werden, um das Cookie zu erhalten.

Vorbeugungsmaßnahmen

  1. SSL/TLS-Konfigurationen sollten vorzugsweise AES verwenden statt DES. Die in Red Hat Enterprise Linux 6 und 7 verwendeten Versionen von OpenSSL tun dies bereits.
  2. In den in Red Hat Enterprise Linux 5 verwendeten Versionen von OpenSSL ist 3DES unter dem AES-256 Verschlüsselungsalgorithmus gelistet und über dem AES-128 Verschlüsselungsalgorithmus, weshalb AES-256-basierte Verschlüsselungsalgorithmen nicht auf dem Server deaktiviert werden sollten.
  3. Server, die OpenSSL verwenden, sollten die AES-128- und AES-256-Chiffren nicht deaktivieren. Die in Red Hat Enterprise Linux enthaltenen Apache-Versionen nutzen den standardmäßigen Chiffre-String, in denen AES bevorzugt verwendet wird vor DES/3DES-basierten Chiffren.

Lösung

  1. Dieser Fehler betrifft das Konzept der DES/3DES-Algorithmen und ist kein Implementierungsfehler.
  2. Dieser Fehler hat keine direkten Auswirkungen auf kryptografische Bibliotheken (OpenSSL, NSS und GnuTLS) in Red Hat Enterprise Linux 5, 6 und 7, da es mehrere stärkere Verschlüsselungsalgorithmen gibt, die in den Konfigurationslisten für Standardchiffren höher als 3DES aufgeführt werden.
  3. Für Red Hat Enterprise Linux 5 sollten Sie AES-256-basierte Chiffren nicht auf dem Server deaktivieren. Für Red Hat Enterprise Linux 6 und 7 sollten Sie AES-128- oder AES-256-basierte Chiffren auf dem Server nicht deaktivieren.

Upstream-Sicherheitsfixes:

OpenSSL:

OpenSSL hat dieses Sicherheitsproblem auf den Schweregrad »niedrig« eingestuft. 3DES-Chiffren wurden von der Sicherheitskategorie HIGH in die MEDIUM-Kategorie in der 1.0.2 Branch verschoben und werden in zukünftigen Releases standardmäßig deaktiviert.

NSS:

Mozilla implementierte Datenbeschränkungen für alle Verschlüsselungsalgorithmen.

Verwandte Probleme

Upstream OpenVPN ist ebenfalls vom Sweet32-Angriff gefährdet und wird unter CVE-2016-6329 geführt. Die OpenVPN-Implementation in Red Hat Produkten ist von diesem Problem nicht betroffen.

Verweise

https://access.redhat.com/security/cve/CVE-2016-2183
https://sweet32.info/

Comments