2. Protocol Overview (Protokollübersicht)
Die vom sicheren Kanal verwendeten kryptographischen Parameter werden durch das TLS Handshake Protocol (Handshake-Protokoll) erzeugt. Dieses Unterprotokoll von TLS wird verwendet, wenn Client und Server zum ersten Mal miteinander kommunizieren. Das Handshake-Protokoll ermöglicht es Peers, eine Protokollversion auszuhandeln, kryptographische Algorithmen auszuwählen, sich optional gegenseitig zu authentifizieren und gemeinsames geheimes Schlüsselmaterial zu etablieren. Sobald der Handshake abgeschlossen ist, verwenden die Peers die etablierten Schlüssel, um den Anwendungsschicht-Verkehr zu schützen.
Ein Handshake-Fehler oder ein anderer Protokollfehler löst die Beendigung der Verbindung aus, optional vorangestellt durch eine Alert Message (Alarmnachricht) (Abschnitt 6).
TLS unterstützt drei grundlegende Key Exchange Modes (Schlüsselaustausch-Modi):
- (EC)DHE (Diffie-Hellman über endlichen Körpern oder elliptischen Kurven)
- PSK-only (nur vorgeteilter Schlüssel)
- PSK with (EC)DHE (vorgeteilter Schlüssel mit (EC)DHE)
Abbildung 1 unten zeigt den grundlegenden vollständigen TLS-Handshake:
Client Server
Key ^ ClientHello
Exch | + key_share*
| + signature_algorithms*
| + psk_key_exchange_modes*
v + pre_shared_key* -------->
ServerHello ^ Key
+ key_share* | Exch
+ pre_shared_key* v
{EncryptedExtensions} ^ Server
{CertificateRequest*} v Params
{Certificate*} ^
{CertificateVerify*} | Auth
{Finished} v
<-------- [Application Data*]
^ {Certificate*}
Auth | {CertificateVerify*}
v {Finished} -------->
[Application Data] <-------> [Application Data]
+ Zeigt bemerkenswerte Erweiterungen an, die in der
zuvor erwähnten Nachricht gesendet werden.
* Zeigt optionale oder situationsabhängige
Nachrichten/Erweiterungen an, die nicht immer gesendet werden.
{} Zeigt Nachrichten an, die mit Schlüsseln geschützt sind,
die von einem [sender]_handshake_traffic_secret abgeleitet wurden.
[] Zeigt Nachrichten an, die mit Schlüsseln geschützt sind,
die von [sender]_application_traffic_secret_N abgeleitet wurden.
Abbildung 1: Nachrichtenfluss für vollständigen TLS-Handshake
Der Handshake kann als drei Phasen betrachtet werden (im obigen Diagramm angegeben):
-
Key Exchange (Schlüsselaustausch): Gemeinsames Schlüsselmaterial etablieren und kryptographische Parameter auswählen. Alles nach dieser Phase ist verschlüsselt.
-
Server Parameters (Server-Parameter): Andere Handshake-Parameter etablieren (ob der Client authentifiziert ist, Anwendungsschicht-Protokollunterstützung usw.).
-
Authentication (Authentifizierung): Den Server (und optional den Client) authentifizieren und Schlüsselbestätigung und Handshake-Integrität bereitstellen.
In der Key Exchange-Phase sendet der Client die ClientHello-Nachricht (Abschnitt 4.1.2), die eine Zufallszahl (ClientHello.random) enthält; seine angebotenen Protokollversionen; eine Liste von symmetrischen Cipher/HKDF-Hash-Paaren; entweder einen Satz von Diffie-Hellman-Schlüsselanteilen (in der "key_share"-Erweiterung (Abschnitt 4.2.8)), einen Satz von vorgeteilten Schlüssellabels (in der "pre_shared_key"-Erweiterung (Abschnitt 4.2.11)) oder beides; und potenziell zusätzliche Erweiterungen. Zusätzliche Felder und/oder Nachrichten können auch für Middlebox-Kompatibilität vorhanden sein.
Der Server verarbeitet das ClientHello und bestimmt die geeigneten kryptographischen Parameter für die Verbindung. Er antwortet dann mit seinem eigenen ServerHello (Abschnitt 4.1.3), das die ausgehandelten Verbindungsparameter angibt. Die Kombination von ClientHello und ServerHello bestimmt die gemeinsamen Schlüssel. Wenn (EC)DHE-Schlüsseletablierung verwendet wird, dann enthält das ServerHello eine "key_share"-Erweiterung mit dem ephemeren Diffie-Hellman-Anteil des Servers; der Anteil des Servers MUSS in derselben Gruppe wie einer der Anteile des Clients sein. Wenn PSK-Schlüsseletablierung verwendet wird, dann enthält das ServerHello eine "pre_shared_key"-Erweiterung, die angibt, welcher der vom Client angebotenen PSKs ausgewählt wurde. Beachten Sie, dass Implementierungen (EC)DHE und PSK zusammen verwenden können, in diesem Fall werden beide Erweiterungen bereitgestellt.
Der Server sendet dann zwei Nachrichten, um die Server Parameters zu etablieren:
EncryptedExtensions: Antworten auf ClientHello-Erweiterungen, die nicht zur Bestimmung der kryptographischen Parameter erforderlich sind, außer solchen, die für einzelne Zertifikate spezifisch sind. [Abschnitt 4.3.1]
CertificateRequest: Wenn zertifikatbasierte Client-Authentifizierung gewünscht ist, die gewünschten Parameter für dieses Zertifikat. Diese Nachricht wird weggelassen, wenn Client-Authentifizierung nicht gewünscht ist. [Abschnitt 4.3.2]
Schließlich tauschen Client und Server Authentication-Nachrichten aus. TLS verwendet denselben Satz von Nachrichten, wann immer zertifikatbasierte Authentifizierung erforderlich ist. (PSK-basierte Authentifizierung erfolgt als Nebeneffekt des Schlüsselaustauschs.) Konkret:
Certificate: Das Zertifikat des Endpunkts und alle Erweiterungen pro Zertifikat. Diese Nachricht wird vom Server weggelassen, wenn er sich nicht mit einem Zertifikat authentifiziert, und vom Client, wenn der Server kein CertificateRequest gesendet hat (was anzeigt, dass der Client sich nicht mit einem Zertifikat authentifizieren sollte). Beachten Sie, dass wenn Raw Public Keys [RFC7250] oder die Cached Information Extension [RFC7924] verwendet werden, diese Nachricht kein Zertifikat, sondern einen anderen Wert enthält, der dem langfristigen Schlüssel des Servers entspricht. [Abschnitt 4.4.2]
CertificateVerify: Eine Signatur über den gesamten Handshake unter Verwendung des privaten Schlüssels, der dem öffentlichen Schlüssel in der Certificate-Nachricht entspricht. Diese Nachricht wird weggelassen, wenn sich der Endpunkt nicht über ein Zertifikat authentifiziert. [Abschnitt 4.4.3]
Finished: Ein MAC (Message Authentication Code) über den gesamten Handshake. Diese Nachricht bietet Schlüsselbestätigung, bindet die Identität des Endpunkts an die ausgetauschten Schlüssel und authentifiziert im PSK-Modus auch den Handshake. [Abschnitt 4.4.4]
Nach Erhalt der Nachrichten des Servers antwortet der Client mit seinen Authentifizierungs-Nachrichten, nämlich Certificate und CertificateVerify (falls angefordert) und Finished.
An diesem Punkt ist der Handshake abgeschlossen, und Client und Server leiten das Schlüsselmaterial ab, das von der Record-Schicht benötigt wird, um Anwendungsschicht-Daten auszutauschen, die durch authentifizierte Verschlüsselung geschützt sind. Application Data DÜRFEN NICHT vor dem Senden der Finished-Nachricht gesendet werden, außer wie in Abschnitt 2.3 spezifiziert. Beachten Sie, dass obwohl der Server Application Data senden kann, bevor er die Authentifizierungs-Nachrichten des Clients empfängt, alle zu diesem Zeitpunkt gesendeten Daten natürlich an einen nicht authentifizierten Peer gesendet werden.
2.1 Incorrect DHE Share (Falscher DHE-Anteil)
Wenn der Client keine ausreichende "key_share"-Erweiterung bereitgestellt hat (z.B. enthält er nur DHE- oder ECDHE-Gruppen, die für den Server nicht akzeptabel oder nicht unterstützt werden), korrigiert der Server die Nichtübereinstimmung mit einem HelloRetryRequest, und der Client muss den Handshake mit einer geeigneten "key_share"-Erweiterung neu starten, wie in Abbildung 2 gezeigt. Wenn keine gemeinsamen kryptographischen Parameter ausgehandelt werden können, MUSS der Server den Handshake mit einer geeigneten Alarm abbrechen.
Client Server
ClientHello
+ key_share -------->
HelloRetryRequest
<-------- + key_share
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
[Application Data] <-------> [Application Data]
Abbildung 2: Nachrichtenfluss für vollständigen Handshake mit
nicht übereinstimmenden Parametern
Hinweis: Das Handshake Transcript (Handshake-Transkript) enthält den anfänglichen ClientHello/HelloRetryRequest-Austausch; es wird nicht mit dem neuen ClientHello zurückgesetzt.
TLS erlaubt auch mehrere optimierte Varianten des grundlegenden Handshakes, wie in den folgenden Abschnitten beschrieben.
2.2 Resumption and Pre-Shared Key (PSK) (Wiederaufnahme und vorgeteilter Schlüssel)
Obwohl TLS-PSKs außerhalb des Bandes etabliert werden können, können PSKs auch in einer vorherigen Verbindung etabliert und dann zur Etablierung einer neuen Verbindung verwendet werden ("Session Resumption (Sitzungsfortsetzung)" oder "Wiederaufnahme" mit einem PSK). Sobald ein Handshake abgeschlossen ist, kann der Server dem Client eine PSK Identity (PSK-Identität) senden, die einem eindeutigen Schlüssel entspricht, der vom anfänglichen Handshake abgeleitet wurde (siehe Abschnitt 4.6.1). Der Client kann diese PSK-Identität dann in zukünftigen Handshakes verwenden, um die Verwendung des zugehörigen PSK auszuhandeln. Wenn der Server den PSK akzeptiert, ist der Sicherheitskontext der neuen Verbindung kryptographisch an die ursprüngliche Verbindung gebunden, und der vom anfänglichen Handshake abgeleitete Schlüssel wird verwendet, um den kryptographischen Zustand zu bootstrappen, anstatt einen vollständigen Handshake durchzuführen. In TLS 1.2 und darunter wurde diese Funktionalität durch "Session IDs (Sitzungs-IDs)" und "Session Tickets (Sitzungstickets)" [RFC5077] bereitgestellt. Beide Mechanismen sind in TLS 1.3 veraltet.
PSKs können mit (EC)DHE-Schlüsselaustausch verwendet werden, um Forward Secrecy in Kombination mit gemeinsamen Schlüsseln bereitzustellen, oder können allein verwendet werden, auf Kosten des Verlusts der Forward Secrecy für Anwendungsdaten.
Abbildung 3 zeigt ein Paar von Handshakes, bei denen der erste einen PSK etabliert und der zweite ihn verwendet:
Client Server
Initial Handshake:
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
<-------- [NewSessionTicket]
[Application Data] <-------> [Application Data]
Subsequent Handshake:
ClientHello
+ key_share*
+ pre_shared_key -------->
ServerHello
+ pre_shared_key
+ key_share*
{EncryptedExtensions}
{Finished}
<-------- [Application Data*]
{Finished} -------->
[Application Data] <-------> [Application Data]
Abbildung 3: Nachrichtenfluss für Wiederaufnahme und PSK
Da der Server über einen PSK authentifiziert wird, sendet er keine Certificate- oder CertificateVerify-Nachricht. Wenn ein Client die Wiederaufnahme über einen PSK anbietet, SOLLTE er dem Server auch eine "key_share"-Erweiterung bereitstellen, um es dem Server zu ermöglichen, die Wiederaufnahme abzulehnen und auf einen vollständigen Handshake zurückzufallen, falls erforderlich. Der Server antwortet mit einer "pre_shared_key"-Erweiterung, um die Verwendung der PSK-Schlüsseletablierung auszuhandeln, und kann (wie hier gezeigt) mit einer "key_share"-Erweiterung antworten, um (EC)DHE-Schlüsseletablierung durchzuführen und so Forward Secrecy bereitzustellen.
Wenn PSKs außerhalb des Bandes bereitgestellt werden, MÜSSEN die PSK-Identität und der KDF-Hash-Algorithmus, der mit dem PSK verwendet werden soll, ebenfalls bereitgestellt werden.
Hinweis: Bei Verwendung eines außerhalb des Bandes bereitgestellten vorgeteilten Geheimnisses ist eine kritische Überlegung die Verwendung ausreichender Entropie während der Schlüsselgenerierung, wie in [RFC4086] diskutiert. Die Ableitung eines gemeinsamen Geheimnisses aus einem Passwort oder anderen Quellen mit geringer Entropie ist nicht sicher. Ein Geheimnis oder Passwort mit geringer Entropie ist anfällig für Wörterbuchangriffe basierend auf dem PSK Binder (PSK-Binder). Die spezifizierte PSK-Authentifizierung ist kein starker passwortbasierter authentifizierter Schlüsselaustausch, selbst wenn sie mit Diffie-Hellman-Schlüsseletablierung verwendet wird. Konkret verhindert sie nicht, dass ein Angreifer, der den Handshake beobachten kann, einen Brute-Force-Angriff auf das Passwort/den vorgeteilten Schlüssel durchführt.
2.3 0-RTT Data (0-RTT-Daten)
Wenn Clients und Server einen PSK teilen (entweder extern erhalten oder über einen vorherigen Handshake), erlaubt TLS 1.3 Clients, Daten beim ersten Flug zu senden ("Early Data (Frühe Daten)"). Der Client verwendet den PSK, um den Server zu authentifizieren und die frühen Daten zu verschlüsseln.
Wie in Abbildung 4 gezeigt, werden die 0-RTT-Daten einfach zum 1-RTT-Handshake beim ersten Flug hinzugefügt. Der Rest des Handshakes verwendet dieselben Nachrichten wie für einen 1-RTT-Handshake mit PSK-Wiederaufnahme.
Client Server
ClientHello
+ early_data
+ key_share*
+ psk_key_exchange_modes
+ pre_shared_key
(Application Data*) -------->
ServerHello
+ pre_shared_key
+ key_share*
{EncryptedExtensions}
+ early_data*
{Finished}
<-------- [Application Data*]
(EndOfEarlyData)
{Finished} -------->
[Application Data] <-------> [Application Data]
+ Zeigt bemerkenswerte Erweiterungen an, die in der
zuvor erwähnten Nachricht gesendet werden.
* Zeigt optionale oder situationsabhängige
Nachrichten/Erweiterungen an, die nicht immer gesendet werden.
() Zeigt Nachrichten an, die mit Schlüsseln geschützt sind,
die von einem client_early_traffic_secret abgeleitet wurden.
{} Zeigt Nachrichten an, die mit Schlüsseln geschützt sind,
die von einem [sender]_handshake_traffic_secret abgeleitet wurden.
[] Zeigt Nachrichten an, die mit Schlüsseln geschützt sind,
die von [sender]_application_traffic_secret_N abgeleitet wurden.
Abbildung 4: Nachrichtenfluss für einen 0-RTT-Handshake
WICHTIGER HINWEIS: Die Sicherheitseigenschaften von 0-RTT-Daten sind schwächer als die anderer Arten von TLS-Daten. Konkret:
-
Diese Daten sind nicht Forward Secret (vorwärtsgeheim), da sie ausschließlich unter Schlüsseln verschlüsselt sind, die vom angebotenen PSK abgeleitet wurden.
-
Es gibt keine Garantien für Non-Replay (Nicht-Wiederholung) zwischen Verbindungen. Der Replay-Schutz für gewöhnliche TLS 1.3 1-RTT-Daten wird über den Random-Wert des Servers bereitgestellt, aber 0-RTT-Daten hängen nicht vom ServerHello ab und haben daher schwächere Garantien. Dies ist besonders relevant, wenn die Daten mit TLS-Client-Authentifizierung oder innerhalb des Anwendungsprotokolls authentifiziert werden. Dieselben Warnungen gelten für jede Verwendung des early_exporter_master_secret.
0-RTT-Daten können nicht innerhalb einer Verbindung dupliziert werden (d.h. der Server wird dieselben Daten nicht zweimal für dieselbe Verbindung verarbeiten), und ein Angreifer wird nicht in der Lage sein, 0-RTT-Daten als 1-RTT-Daten erscheinen zu lassen (da sie mit unterschiedlichen Schlüsseln geschützt sind). Anhang E.5 enthält eine Beschreibung potenzieller Angriffe, und Abschnitt 8 beschreibt Mechanismen, die der Server verwenden kann, um die Auswirkungen von Replay zu begrenzen.