Informationen über das Neue (CVE-2020-1968) im TLS-Protokoll, Codename
und ermöglicht in seltenen Fällen die Bestimmung eines vorläufigen Primärschlüssels (Pre-Master), der zum Entschlüsseln von TLS-Verbindungen, einschließlich HTTPS, beim Abfangen von Transitverkehr (MITM) verwendet werden kann. Es wird darauf hingewiesen, dass der Angriff nur sehr schwer in die Praxis umzusetzen ist und eher theoretischer Natur ist. Um einen Angriff durchzuführen, sind eine spezifische Konfiguration des TLS-Servers und die Fähigkeit erforderlich, die Serververarbeitungszeit sehr genau zu messen.
Das Problem liegt direkt in der TLS-Spezifikation vor und betrifft nur Verbindungen, die Chiffren verwenden, die auf dem DH-Schlüsselaustauschprotokoll (Diffie-Hellman, TLS_DH_*") basieren. Bei ECDH-Verschlüsselungen tritt das Problem nicht auf und sie bleiben sicher. Nur TLS-Protokolle bis Version 1.2 sind anfällig; TLS 1.3 ist von dem Problem nicht betroffen. Die Sicherheitslücke tritt bei TLS-Implementierungen auf, die den geheimen DH-Schlüssel über verschiedene TLS-Verbindungen hinweg wiederverwenden (dieses Verhalten tritt bei etwa 4.4 % der Alexa Top 1M-Server auf).
In OpenSSL 1.0.2e und früheren Versionen wird der DH-Primärschlüssel in allen Serververbindungen wiederverwendet, sofern die Option SSL_OP_SINGLE_DH_USE nicht explizit festgelegt ist. Seit OpenSSL 1.0.2f wird der DH-Primärschlüssel nur noch bei Verwendung statischer DH-Chiffren („DH-*“, z. B. „DH-RSA-AES256-SHA“) wiederverwendet. Die Schwachstelle tritt in OpenSSL 1.1.1 nicht auf, da dieser Zweig keinen DH-Primärschlüssel und keine statischen DH-Verschlüsselungen verwendet.
Bei Verwendung der DH-Schlüsselaustauschmethode generieren beide Seiten der Verbindung zufällige private Schlüssel (im Folgenden Schlüssel „a“ und Schlüssel „b“), auf deren Grundlage öffentliche Schlüssel (ga mod p und gb mod p) berechnet und gesendet werden. Nachdem jede Partei die öffentlichen Schlüssel erhalten hat, wird ein gemeinsamer Primärschlüssel (gab mod p) berechnet, der zur Generierung von Sitzungsschlüsseln verwendet wird. Der Raccoon-Angriff ermöglicht es Ihnen, den Primärschlüssel durch Seitenkanalanalyse zu bestimmen, basierend auf der Tatsache, dass die TLS-Spezifikationen bis Version 1.2 erfordern, dass alle führenden Nullbytes des Primärschlüssels verworfen werden, bevor Berechnungen, die ihn betreffen, verworfen werden.
Einschließlich des abgeschnittenen Primärschlüssels wird er an die Sitzungsschlüsselgenerierungsfunktion übergeben, die auf Hash-Funktionen mit unterschiedlichen Verzögerungen bei der Verarbeitung verschiedener Daten basiert. Durch die genaue Messung des Timings der vom Server durchgeführten Schlüsseloperationen kann der Angreifer Hinweise (Orakel) ermitteln, anhand derer beurteilt werden kann, ob der Primärschlüssel bei Null beginnt oder nicht. Beispielsweise könnte ein Angreifer den vom Client gesendeten öffentlichen Schlüssel (ga) abfangen, ihn erneut an den Server übertragen und ermitteln
ob der resultierende Primärschlüssel bei Null beginnt.
Die Definition eines Bytes des Schlüssels allein bringt nichts, aber durch das Abfangen des vom Client während der Verbindungsaushandlung übermittelten „ga“-Werts kann der Angreifer eine Reihe anderer mit „ga“ verknüpfter Werte generieren und diese an senden den Server in separaten Verbindungsaushandlungssitzungen. Durch das Generieren und Senden von „gri*ga“-Werten kann ein Angreifer durch die Analyse von Verzögerungen in der Serverantwort die Werte ermitteln, die zum Empfang von Primärschlüsseln beginnend bei Null führen. Nachdem der Angreifer solche Werte ermittelt hat, kann er eine Reihe von Gleichungen dafür erstellen und berechnen Sie den ursprünglichen Primärschlüssel.
OpenSSL-Schwachstellen geringes Gefahrenniveau, und der Fix beschränkte sich darauf, die problematischen Chiffren „TLS_DH_*“ in Version 1.0.2w in die Kategorie der Chiffren mit unzureichendem Schutzniveau („weak-ssl-ciphers“) zu verschieben, die standardmäßig deaktiviert ist . Die Mozilla-Entwickler haben das Gleiche getan, in der in Firefox verwendeten NSS-Bibliothek die DH- und DHE-Verschlüsselungssammlungen. Ab Firefox 78 sind problematische Verschlüsselungen deaktiviert. Die Chrome-Unterstützung für DH wurde bereits 2016 eingestellt. Die Bibliotheken BearSSL, BoringSSL, Botan, Mbed TLS und s2n sind von dem Problem nicht betroffen, da sie keine DH-Verschlüsselungen oder statischen Varianten von DH-Verschlüsselungen unterstützen.
Zusätzliche Probleme werden gesondert vermerkt () im TLS-Stack von F5 BIG-IP-Geräten, wodurch der Angriff realistischer wird. Insbesondere wurden Abweichungen im Verhalten von Geräten bei Vorhandensein eines Nullbytes am Anfang des Primärschlüssels identifiziert, die anstelle der Messung der genauen Latenz von Berechnungen genutzt werden können.
Source: opennet.ru