Zum Hauptinhalt springen

1. Introduction (Einführung)

1. Introduction (Einführung)​

In TLS [RFC5246] hat jede Sitzung ein master_secret, das wie folgt berechnet wird:

master_secret = PRF(pre_master_secret, "master secret",
                    ClientHello.random + ServerHello.random)
                    [0..47];

wobei das pre_master_secret das Ergebnis eines Schlüsselaustauschprotokolls ist. Wenn der Handshake beispielsweise eine RSA-Verschlüsselungssammlung verwendet, wird dieser Wert vom Client gleichmäßig zufällig generiert, während er bei Ephemeral Diffie-Hellman (DHE)-Verschlüsselungssammlungen das Ergebnis einer Diffie-Hellman-Schlüsselvereinbarung ist.

Wie in [TRIPLE-HS] beschrieben, kann ein aktiver Angreifer sowohl beim RSA- als auch beim DHE-Schlüsselaustausch zwei TLS-Sitzungen synchronisieren, so dass sie dasselbe master_secret teilen. Bei einem RSA-Schlüsselaustausch, bei dem der Client nicht authentifiziert ist, wird dies wie folgt erreicht. Angenommen, ein Client C verbindet sich mit einem Server A. C bemerkt nicht, dass A bösartig ist und dass A im Hintergrund eine Verbindung zu einem ehrlichen Server S herstellt und beide Handshakes abschließt. Der Einfachheit halber nehmen wir an, dass C und S nur RSA-Verschlüsselungssammlungen verwenden.

  1. C sendet ein ClientHello an A, und A leitet es an S weiter.

  2. S sendet ein ServerHello an A, und A leitet es an C weiter.

  3. S sendet ein Certificate an A, das seine Zertifikatskette enthält. A ersetzt es durch seine eigene Zertifikatskette und sendet es an C.

  4. S sendet ein ServerHelloDone an A, und A leitet es an C weiter.

  5. C sendet einen ClientKeyExchange an A, der das mit As öffentlichem Schlüssel verschlüsselte pre_master_secret enthält. A entschlüsselt das pre_master_secret, verschlüsselt es erneut mit Ss öffentlichem Schlüssel und sendet es an S weiter.

  6. C sendet ein Finished an A. A berechnet ein Finished für seine Verbindung mit S und sendet es an S.

  7. S sendet ein Finished an A. A berechnet ein Finished für seine Verbindung mit C und sendet es an C.

Zu diesem Zeitpunkt haben beide Verbindungen (zwischen C und A und zwischen A und S) neue Sitzungen, die dasselbe pre_master_secret, ClientHello.random, ServerHello.random sowie andere Sitzungsparameter, einschließlich der Sitzungskennung und optional des Sitzungstickets, teilen. Daher ist der Wert des master_secret für die beiden Sitzungen gleich und wird sowohl bei C als auch bei S mit derselben Sitzungs-ID verknüpft, obwohl die Serveridentitäten bei den beiden Verbindungen unterschiedlich sind. Erinnern Sie sich daran, dass C nur das Zertifikat von A sieht und nichts von der Verbindung von A zu S weiß. Außerdem sind die Datenschlüssel (record keys) auf den beiden Verbindungen ebenfalls gleich.

Das obige Szenario zeigt, dass TLS nicht garantiert, dass die bei verschiedenen Verbindungen verwendeten Hauptgeheimnisse und Schlüssel unterschiedlich sind. Selbst wenn eine Client-Authentifizierung verwendet wird, funktioniert das Szenario immer noch, außer dass sich die beiden Sitzungen nun sowohl hinsichtlich der Client- als auch der Serveridentität unterscheiden.

Ein ähnliches Szenario kann erreicht werden, wenn der Handshake eine DHE-Verschlüsselungssammlung verwendet. Beachten Sie, dass selbst wenn der Client oder Server die Verwendung von RSA oder DHE nicht bevorzugt, der Angreifer sie dazu zwingen kann, indem er in seinen Hello-Nachrichten nur RSA oder DHE anbietet. Handshakes, die Ephemeral Elliptic Curve Diffie-Hellman (ECDHE)-Verschlüsselungssammlungen verwenden, sind ebenfalls anfällig, wenn sie beliebige explizite Kurven zulassen oder Kurven mit kleinen Untergruppen verwenden. Gegen mächtigere Gegner haben sich auch andere Schlüsselaustausche wie Secure Remote Password (SRP) und Pre-Shared Key (PSK) als anfällig erwiesen [VERIFIED-BINDINGS].

Sobald A die beiden Verbindungen synchronisiert hat, kann A, da die Schlüssel auf beiden Seiten gleich sind, zurücktreten und Nachrichten transparent zwischen C und S weiterleiten, wobei A nach Belieben lesen und ändern kann. In der Literatur zum Schlüsselaustausch werden solche Vorkommnisse als Unknown-Key-Share-Angriffe bezeichnet, da C und S ein Geheimnis teilen, aber beide denken, dass ihr Geheimnis nur mit A geteilt wird. An sich brechen diese Angriffe nicht die Integrität oder Vertraulichkeit zwischen ehrlichen Parteien, aber sie bieten einen nützlichen Ausgangspunkt, um Identitätsdiebstähle bei C und S durchzuführen.

Angenommen, C versucht, seine Sitzung über eine neue Verbindung mit A wiederaufzunehmen. A kann dann seine Sitzung mit S über eine neue Verbindung wiederaufnehmen und die verkürzten Handshake-Nachrichten unverändert zwischen C und S weiterleiten. Da der verkürzte Handshake nur auf dem Hauptgeheimnis zur Authentifizierung beruht und weder Client- noch Serveridentitäten erwähnt, werden beide Handshakes erfolgreich abgeschlossen, was zu denselben Sitzungsschlüsseln und demselben Handshake-Protokoll führt. A kennt weiterhin die Verbindungsschlüssel und kann Nachrichten sowohl an C als auch an S senden.

Kritischerweise ist bei der neuen Verbindung sogar das Handshake-Protokoll bei C und S gleich, wodurch jedes Man-in-the-Middle-Schutzschema, das auf der Eindeutigkeit von Finished-Nachrichten beruht, wie z. B. die Erweiterung für sichere Neuverhandlung (Secure Renegotiation Indication Extension) [RFC5746] oder TLS-Kanalbindungen (Channel Bindings) [RFC5929], ausgehebelt wird. [TRIPLE-HS] beschreibt mehrere Exploits, die auf solchen Sitzungssynchronisationsangriffen basieren. Insbesondere wird ein Man-in-the-Middle-Angriff beschrieben, der als "Triple Handshake" bezeichnet wird und die Schutzmaßnahmen von [RFC5746] umgeht, um die Client-authentifizierte TLS-Neuverhandlung nach der Sitzungswiederaufnahme zu brechen. Ähnliche Angriffe gelten für Authentifizierungsmechanismen auf Anwendungsebene, die auf Kanalbindungen [RFC5929] oder auf aus TLS exportiertem Schlüsselmaterial [RFC5705] beruhen.

Das zugrunde liegende Protokollproblem, das zu diesen Angriffen führt, besteht darin, dass nicht garantiert ist, dass das TLS-Hauptgeheimnis über Sitzungen hinweg eindeutig ist, da es nicht kontextgebunden an den vollständigen Handshake ist, der es generiert hat. Wenn wir dieses Problem bei der anfänglichen Berechnung des Hauptgeheimnisses beheben, können alle diese Angriffe verhindert werden. Diese Spezifikation führt eine TLS-Erweiterung ein, die die Art und Weise ändert, wie der Wert master_secret in einem vollständigen Handshake berechnet wird, indem das Protokoll der Handshake-Nachrichten einbezogen wird, so dass verschiedene Sitzungen konstruktionsbedingt unterschiedliche Hauptgeheimnisse haben. Dies verhindert die in [TRIPLE-HS] beschriebenen und in Abschnitt 2.11 von [RFC7457] dokumentierten Angriffe.

Letztes Update am