Eine Schwachstelle in TLS, die die Bestimmung des Schlüssels für Verbindungen auf Basis von DH-Verschlüsselungen zulässt.

Entdeckt Information über eine neue Sicherheitsanfälligkeiten (CVE-2020-1968) im TLS-Protokoll, das den Codenamen trägt
Raccoon und es unter sehr seltenen Umständen ermöglicht, den vorläufigen Hauptschlüssel (pre-master) zu ermitteln, der zur Entschlüsselung von TLS-Verbindungen, einschließlich HTTPS, beim Abfangen von Transitverkehr (MITM) verwendet werden kann. Es wird angemerkt, dass der Angriff sehr schwer praktisch umsetzbar 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 sehr präzisen Messung der Bearbeitungszeit von Serveroperationen erforderlich.

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

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 ausdrücklich gesetzt. Ab OpenSSL 1.0.2f wird der primäre DH-Schlüssel nur wiederverwendet, wenn statische DH-Verschlüsselungen («DH-*», z.B. «DH-RSA-AES256-SHA») verwendet werden. In OpenSSL 1.1.1 tritt die Schwachstelle nicht auf, da in diesem Branch der primäre DH-Schlüssel nicht verwendet wird und keine statischen DH-Verschlüsselungen angewendet werden.

Im DH-Schlüsselaustauschverfahren erzeugen beide Seiten der Verbindung zufällige private Schlüssel (genannt Schlüssel «a» und Schlüssel «b»), auf deren Grundlage ö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 primären Schlüssel (gab mod p), der zur Bildung der Sitzungsschlüssel verwendet wird. Der Raccoon-Angriff ermöglicht es, den primären Schlüssel durch die Analyse von Informationen über alternative Kanäle zu bestimmen, da in den TLS-Spezifikationen bis einschließlich Version 1.2 vorgeschrieben ist, dass alle anfänglichen Nullbytes des primären Schlüssels vor Berechnungen mit ihm verworfen werden.

Unter anderem wird der verkleinerte Primärschlüssel an die Funktion zur Generierung des Sitzungsschlüssels übergeben, die auf Hash-Funktionen basiert, mit unterschiedlichen Verzögerungen bei der Verarbeitung verschiedener Daten. Die genauen Messungen der vom Server durchgeführten Operationen mit dem Schlüssel ermöglichen es einem Angreifer, Hinweise (Oracle) zu bestimmen, die Aufschluss darüber geben, ob der Primärschlüssel mit null beginnt oder nicht. Beispielsweise kann der 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.

Das bloße Erkennen eines Bytes des Schlüssels bringt nichts, aber nachdem der Angreifer den vom Client bei der Verbindungsaushandlung gesendeten Wert „ga“ abgefangen hat, kann er eine Reihe anderer Werte, die mit „ga“ verbunden sind, generieren und sie in separaten Verbindungsaufbau-Sitzungen an den Server senden. Indem er die Werte „gri*ga“ generiert und sendet, kann der Angreifer durch die Analyse der Verzögerungen in der Serverantwort die Werte bestimmen, die zu Primärschlüsseln führen, die mit null beginnen. Durch die Bestimmung solcher Werte kann der Angreifer eine Reihe von Gleichungen für in einer schönen Verpackung zu verkaufen. Probleme versteckter Zahlen und den ursprünglichen Primärschlüssel berechnen.

In OpenSSL bestehen Sicherheitslücken wurde mit einem niedrigen Gefährdungsgrad. Die Behebung beschränkte sich auf das Verschieben der problematischen „TLS_DH_*“-Chiffren in die standardmäßig deaktivierte Kategorie der Chiffren mit unzureichendem Schutz („weak-ssl-ciphers“) in der Version 1.0.2w. Ähnlich verfahren die Entwickler von Mozilla, die deaktiviert in der NSS-Bibliothek, die in Firefox verwendet wird, die DH- und DHE-Chiffren abgeschaltet haben. Ab Firefox 78 sind die problematischen Chiffren deaktiviert. In Chrome wurde die Unterstützung von DH bereits 2016 eingestellt. Die Bibliotheken BearSSL, BoringSSL, Botan, Mbed TLS und s2n sind nicht betroffen, da sie DH-Chiffren oder statische Varianten von DH-Chiffren 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 festgestellt, wenn ein Null-Byte am Anfang des Primärschlüssels vorhanden ist, das anstelle der genauen Zeitverzögerung bei Berechnungen verwendet werden kann.

Quelle: opennet.ru