6. Security Considerations (Sicherheitsüberlegungen)

6.1. Triple Handshake Preconditions and Impact (Voraussetzungen und Auswirkungen des Triple Handshake)

Eine Möglichkeit, einen Triple Handshake-Angriff durchzuführen, wird in Section 1 beschrieben, zusammen mit einer Erwähnung der Sicherheitsmechanismen, die aufgrund des Angriffs brechen; eine ausführlichere Diskussion und Diagramme finden sich in [TRIPLE-HS]. Hier werden einige weitere Diskussionen über die Voraussetzungen und Auswirkungen des Angriffs präsentiert.

Um einen Triple Handshake-Angriff durchzuführen, muss es möglich sein, dasselbe Hauptgeheimnis in zwei verschiedenen Sitzungen zu erzwingen. Damit dies geschehen kann, müssen zwei Voraussetzungen erfüllt sein:

Der Client, C, muss bereit sein, sich mit einem bösartigen Server, A, zu verbinden. In bestimmten Kontexten, wie dem Web, kann dies leicht erreicht werden, da ein Browser angewiesen werden kann, Inhalte von einer nicht vertrauenswürdigen Quelle zu laden.
Das Vor-Hauptgeheimnis muss in den beiden Sitzungen synchronisiert sein. Dies ist besonders einfach mit den RSA- und DHE-Schlüsselaustauschen zu erreichen, aber unter bestimmten Bedingungen können auch ECDHE-, SRP- und PSK-Schlüsselaustausche zu diesem Zweck ausgenutzt werden.

Sobald das Hauptgeheimnis in zwei Sitzungen synchronisiert ist, ist jede Sicherheitseigenschaft, die auf der Eindeutigkeit des Hauptgeheimnisses beruht, kompromittiert. Beispielsweise stellt ein TLS-Exporter [RFC5705] keinen eindeutigen Schlüssel mehr bereit, der an die aktuelle Sitzung gebunden ist.

Die TLS-Sitzungswiederaufnahme verlässt sich ebenfalls auf die Eindeutigkeit des Hauptgeheimnisses, um die wiederaufnehmenden Peers zu authentifizieren. Wenn also eine synchronisierte Sitzung wiederaufgenommen wird, können sich die Peers über die Identität des anderen nicht sicher sein, und der Angreifer kennt die Verbindungsschlüssel. Offensichtlich ist eine Voraussetzung für diesen Schritt des Angriffs, dass sowohl Client als auch Server die Sitzungswiederaufnahme unterstützen (entweder über Sitzungskennung oder Sitzungstickets [RFC5077]).

Darüber hinaus ist in einem synchronisierten verkürzten Handshake das gesamte Transkript (das die verify_data-Werte enthält) synchronisiert. Nach einem verkürzten Handshake identifizieren Kanalbindungen wie "tls-unique" [RFC5929] die Verbindung also nicht mehr eindeutig.

Die Synchronisierung der verify_data in verkürzten Handshakes untergräbt auch die Sicherheitsgarantien der Erweiterung für die Neuverhandlungsanzeige [RFC5746] und aktiviert eine Präfix-Injektions-Schwachstelle ähnlich dem Neuverhandlungsangriff [Ray09] wieder. Bei einem Triple Handshake-Angriff sieht der Client jedoch, dass sich das Serverzertifikat über verschiedene vollständige Handshakes hinweg ändert. Daher ist eine Voraussetzung für die Durchführung dieser Stufe des Angriffs, dass der Client bei jedem Handshake unterschiedliche Zertifikate akzeptiert, auch wenn ihre gemeinsamen Namen nicht übereinstimmen. Bevor der Triple Handshake-Angriff entdeckt wurde, war dies zumindest bei einigen Webbrowsern ein weit verbreitetes Verhalten; solche Browser waren daher anfällig für den Angriff.

Die Erweiterung für das erweiterte Hauptgeheimnis vereitelt Triple Handshake-Angriffe in ihrer ersten Stufe, indem sie sicherstellt, dass verschiedene Sitzungen zwangsläufig unterschiedliche Werte für das Hauptgeheimnis haben. Daher wird nun erwartet, dass alle Sicherheitseigenschaften, die auf der Eindeutigkeit des Hauptgeheimnisses beruhen, bestehen bleiben. Insbesondere wenn eine TLS-Sitzung durch die Erweiterung für das erweiterte Hauptgeheimnis geschützt ist, ist es sicher, sie wiederaufzunehmen, ihre Kanalbindungen zu verwenden und Zertifikatsänderungen während der Neuverhandlung zuzulassen, was bedeutet, dass alle Zertifikate vom selben Peer kontrolliert werden. Eine symbolische kryptografische Protokollanalyse, die die Erweiterung für das erweiterte Hauptgeheimnis rechtfertigt, erscheint in [VERIFIED-BINDINGS].

6.2. Cryptographic Properties of the Hash Function (Kryptografische Eigenschaften der Hash-Funktion)

Die Sitzungshashes zweier verschiedener Sitzungen müssen unterschiedlich sein; daher muss die Hash-Funktion, die zur Berechnung des session_hash verwendet wird, kollisionsresistent sein. Daher werden Hash-Funktionen wie MD5 oder SHA1 NICHT EMPFOHLEN.

Wir stellen fest, dass die Hash-Funktion, die bei der Berechnung der Finished-Nachricht verwendet wird, bereits kollisionsresistent sein muss, damit die Erweiterung für die Neuverhandlungsanzeige [RFC5746] funktioniert, da eine signifikante Kollision bei den Handshake-Nachrichten (und damit bei den verify_data) den Neuverhandlungsangriff [Ray09] wieder aktivieren kann.

Die Hash-Funktion, die zur Berechnung des Sitzungshashs verwendet wird, hängt von der TLS-Protokollversion ab. Alle aktuellen Verschlüsselungssammlungen, die für TLS 1.2 definiert sind, verwenden SHA256 oder besser, und das gilt auch für den Sitzungshash. Für frühere Versionen des Protokolls kann nur angenommen werden, dass MD5 und SHA1 unterstützt werden, und dieses Dokument verlangt von Legacy-Implementierungen nicht, Unterstützung für neue Hash-Funktionen hinzuzufügen. In diesen Versionen verwendet der Sitzungshash die Verkettung von MD5 und SHA1, wie in der Finished-Nachricht.

6.3. Handshake Messages Included in the Session Hash (Im Sitzungshash enthaltene Handshake-Nachrichten)

Der session_hash soll alle relevanten Sitzungsinformationen umfassen, einschließlich der Aushandlung der Verschlüsselungssammlung, der Schlüsselaustauschnachrichten sowie der Client- und Serveridentitäten. Der Hash wird benötigt, um das erweiterte Hauptgeheimnis zu berechnen, und muss daher vor den Finished-Nachrichten verfügbar sein.

Dieses Dokument legt fest, dass der session_hash alle Handshake-Nachrichten bis einschließlich ClientKeyExchange abdeckt. Für bestehende TLS-Verschlüsselungssammlungen enthalten diese Nachrichten alle signifikanten Inhalte der neuen Sitzung -- CertificateVerify ändert den Sitzungsinhalt nicht. Gleichzeitig ermöglicht dies die Berechnung des erweiterten Hauptgeheimnisses unmittelbar nach dem Vor-Hauptgeheimnis, so dass Implementierungen das temporäre Vor-Hauptgeheimnis so früh wie möglich aus dem Speicher löschen können.

Es ist möglich, dass neue Verschlüsselungssammlungen oder TLS-Erweiterungen zusätzliche Nachrichten zwischen ClientKeyExchange und Finished enthalten, die wichtigen Sitzungskontext hinzufügen. In solchen Fällen gelten einige der Sicherheitsgarantien dieser Spezifikation möglicherweise nicht mehr, und neue Man-in-the-Middle-Angriffe könnten möglich sein. Wenn Client und Server beispielsweise die Sitzungsticket-Erweiterung [RFC5077] unterstützen, deckt der Sitzungshash das vom Server gesendete neue Sitzungsticket nicht ab. Daher kann ein Man-in-the-Middle möglicherweise einen Client dazu bringen, ein Sitzungsticket zu speichern, das nicht für die aktuelle Sitzung bestimmt war. Angriffe auf der Grundlage dieses Vektors sind noch nicht bekannt, aber Anwendungen, die zusätzliche Informationen in Sitzungstickets über die im Sitzungshash abgedeckten hinaus speichern, erfordern eine sorgfältige Analyse.

6.4. No SSL 3.0 Support (Keine SSL 3.0-Unterstützung)

Das Secure Sockets Layer (SSL)-Protokoll Version 3.0 [RFC6101] ist ein Vorgänger des TLS-Protokolls und ebenso anfällig für Triple Handshake-Angriffe sowie für andere Schwachstellen, die sich aus der Verwendung veralteter kryptografischer Konstruktionen ergeben, die heute als schwach gelten. SSL 3.0 wurde abgekündigt [RFC7568].

Die in diesem Dokument beschriebene Gegenmaßnahme beruht auf einer TLS-Erweiterung und kann daher nicht mit SSL 3.0 verwendet werden. Clients und Server, die dieses Dokument implementieren, SOLLTEN SSL 3.0-Handshakes ablehnen. Wenn sie sich entscheiden, SSL 3.0 zu unterstützen, MÜSSEN die resultierenden Sitzungen die Legacy-Hauptschlüsselberechnung verwenden, und die Interoperabilitätsüberlegungen von Section 5.4 gelten.