Eine Schwachstelle in TLS, die die Bestimmung des Schlüssels für Verbindungen auf Basis von DH-Verschlüsselungen ermöglicht.

Enthüllt Information über neu von Schwachstellen (CVE-2020-1968) im TLS-Protokoll, das den Codenamen erhalten hat
Raccoon und unter bestimmten seltenen Umständen den vorläufigen Hauptschlüssel (pre-master) bestimmen kann, der zur Entschlüsselung von TLS-Verbindungen, einschließlich HTTPS, bei der Abfangung von Transitverkehr (MITM) verwendet werden kann. Es wird angemerkt, dass der Angriff sehr schwierig umzusetzen ist und eher theoretischer Natur ist. Für die Durchführung des Angriffs ist eine spezifische Konfiguration des TLS-Servers und die Möglichkeit einer äußerst präzisen Zeitmessung der Serveroperationen erforderlich.

Das Problem liegt direkt in der TLS-Spezifikation und betrifft nur Verbindungen, die Verschlüsselungen auf Basis des DH-Schlüsselaustauschprotokolls (Diffie-Hellman, TLS_DH_*) verwenden. Mit ECDH-Verschlüsselungen tritt das Problem nicht auf, und sie bleiben sicher. Nur TLS-Protokolle bis einschließlich Version 1.2 sind anfällig, das TLS 1.3-Protokoll ist von dem Problem nicht betroffen. Die Schwachstelle tritt in TLS-Implementierungen auf, die den geheimen DH-Schlüssel in verschiedenen TLS-Verbindungen wiederverwenden (dieses Verhalten wird bei etwa 4,4 % der Server im Alexa-Ranking der Top 1M beobachtet).

In OpenSSL 1.0.2e und früheren Versionen wird der primäre DH-Schlüssel in allen Serververbindungen wiederverwendet, es sei denn, die Option SSL_OP_SINGLE_DH_USE ist explizit festgelegt. Ab OpenSSL 1.0.2f wird der primäre DH-Schlüssel nur bei der Verwendung statischer DH-Verschlüsselungen („DH-*“, z. B. „DH-RSA-AES256-SHA“) wiederverwendet. In OpenSSL 1.1.1 tritt die Schwachstelle nicht auf, da in diesem Zweig der primäre DH-Schlüssel nicht verwendet wird und keine statischen DH-Verschlüsselungen angewendet werden.

Bei der Verwendung des DH-Schlüsselaustauschverfahrens generieren beide Seiten der Verbindung zufällige private Schlüssel (weiterhin Schlüssel „a“ und Schlüssel „b“), auf deren Basis öffentliche Schlüssel (ga mod p und gb mod p) berechnet und gesendet werden. Nach dem Erhalt der öffentlichen Schlüssel berechnet jede Seite den gemeinsamen Hauptschlüssel (gab mod p), der zur Bildung von Sitzungsschlüsseln verwendet wird. Der Raccoon-Angriff ermöglicht es, den Hauptschlüssel durch die Analyse von Informationen über Seitensysteme zu bestimmen, wobei davon ausgegangen wird, dass in den Spezifikationen von TLS bis einschließlich Version 1.2 vorgeschrieben ist, alle anfänglichen Null-Bytes des Hauptschlüssels vor der Berechnung, in die er einbezogen wird, zu verwerfen.

Unter anderem wird der gekürzte Primärschlüssel an die Funktion zur Generierung des Sitzungsschlüssels übergeben, die auf Hash-Funktionen mit unterschiedlichen Verarbeitungsverzögerungen bei der Verarbeitung verschiedener Daten basiert. Eine genaue Messung der Zeit, die der Server für Operationen mit dem Schlüssel benötigt, ermöglicht es einem Angreifer, Hinweise (Oracle) zu bestimmen, die darauf hinweisen, ob der Primärschlüssel mit Null beginnt oder nicht. Zum Beispiel kann ein Angreifer den vom Client gesendeten öffentlichen Schlüssel (ga) abfangen, ihn an den Server zurücksenden und feststellen,
ob der resultierende Primärschlüssel mit Null beginnt.

Die Bestimmung eines einzelnen Byte des Schlüssels allein bringt nichts, aber wenn ein Angreifer den während der Verbindungsaushandlung gesendeten Wert „ga“ abfängt, kann er eine Reihe anderer Werte generieren, die mit „ga“ verbunden sind, und sie in separaten Aushandlungssitzungen an den Server senden. Indem er Werte wie „gri*ga“ formt und sendet, kann der Angreifer durch die Analyse von Verzögerungsänderungen in der serverseitigen Antwort die Werte bestimmen, die zu Primärschlüsseln führen, die mit Null beginnen. Hat der Angreifer solche Werte identifiziert, kann er ein Gleichungssystem für in einer schönen Verpackung das Problem der verborgenen Zahlen aufstellen und den ursprünglichen Primärschlüssel berechnen.

In OpenSSL sind die Schwachstellen wurde von geringer Gefährdung, und die Behebung bestand darin, die problematischen Verschlüsselungen „TLS_DH_*“ in die standardmäßig deaktivierte Kategorie von Verschlüsselungen mit unzureichendem Schutzniveau („weak-ssl-ciphers“) zu verschieben. Auch die Entwickler von Mozilla haben dies getan, indem sie deaktiviert in der NSS-Bibliothek, die in Firefox verwendet wird, die DH- und DHE-Verschlüsselungssets deaktiviert haben. Seit Firefox 78 sind die problematischen Verschlüsselungen deaktiviert. In Chrome wurde die Unterstützung für DH bereits 2016 eingestellt. Die Bibliotheken BearSSL, BoringSSL, Botan, Mbed TLS und s2n sind nicht betroffen, da sie DH-Verschlüsselungen oder statische Varianten von DH-Verschlüsselungen nicht unterstützen.

Zusätzlich gibt es weitere Probleme (CVE-2020-5929) im TLS-Stack der F5 BIG-IP-Geräte, die einen Angriff realistischer machen. Insbesondere wurden Abweichungen im Verhalten der Geräte bei einem Null-Byte am Anfang des Primärschlüssels entdeckt, die anstelle der genauen Zeitverzögerungsmessung bei Berechnungen verwendet werden können.

Quelle: opennet.ru