Zum Hauptinhalt springen

2. Notationskonventionen (Notational Conventions)

Die Schlüsselwörter "MUST (MUSS)", "MUST NOT (DARF NICHT)", "REQUIRED (ERFORDERLICH)", "SHALL (SOLL)", "SHALL NOT (SOLL NICHT)", "SHOULD (SOLLTE)", "SHOULD NOT (SOLLTE NICHT)", "RECOMMENDED (EMPFOHLEN)", "NOT RECOMMENDED (NICHT EMPFOHLEN)", "MAY (DARF)" und "OPTIONAL (OPTIONAL)" in diesem Dokument sind wie in BCP 14 [RFC2119] [RFC8174] beschrieben zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.

Dieses Dokument verwendet die in [QUIC-TRANSPORT] etablierte Terminologie.

Aus Gründen der Kürze wird die Abkürzung TLS verwendet, um sich auf TLS 1.3 zu beziehen, obwohl neuere Versionen von TLS verwendet werden können; siehe Abschnitt 4.2.

2.1. TLS-Überblick (TLS Overview)​

TLS bietet eine Möglichkeit für zwei Endpunkte, eine Kommunikationsmöglichkeit über ein unzuverlässiges Medium (wie das Internet) herzustellen. TLS ermöglicht die Authentifizierung von Peers und bietet Vertraulichkeits- und Integritätsschutz für die zwischen den Endpunkten ausgetauschten Nachrichten.

Intern ist TLS ein mehrschichtiges Protokoll mit einer in Abbildung 1 dargestellten Struktur.

         +-------------+------------+--------------+---------+
Inhalts- |             |            |  Anwendungs- |         |
schicht  | Handshake   |   Alert    |    daten     |   ...   |
         |             |            |              |         |
         +-------------+------------+--------------+---------+
Aufzeich-|                                                   |
nungs-   |                   Datensatz                      |
schicht  |                                                   |
         +---------------------------------------------------+

Abbildung 1: TLS-Schichten

Jede Nachricht der Inhaltsschicht (z.B. Handshake, Alert und Anwendungsdaten) wird von der Datensatzschicht als eine Reihe von typisierten TLS-Datensätzen übertragen. Datensätze werden einzeln kryptografisch geschützt und dann über einen zuverlässigen Transport (typischerweise TCP) übertragen, der Ordnung und Liefergarantie bietet.

Der TLS-Authentifizierungs-Schlüsselaustausch-Handshake findet zwischen zwei Endpunkten statt: einem Client und einem Server. Der Client initiiert den Austausch und der Server antwortet. Wenn der Schlüsselaustausch erfolgreich abgeschlossen wird, einigen sich Client und Server auf ein Geheimnis. TLS unterstützt sowohl vorgeteilte Schlüssel (PSK) als auch Diffie-Hellman-Schlüsselaustausch basierend auf endlichen Körpern oder elliptischen Kurven ((EC)DHE). PSKs sind die Grundlage für frühe Daten (0-RTT); letztere bieten Forward Secrecy (FS), wenn (EC)DHE-Schlüssel zerstört werden. Diese beiden Modi können auch kombiniert werden, um Forward Secrecy bei Verwendung eines PSK für die Authentifizierung zu bieten.

Nach Abschluss des TLS-Handshakes hat der Client die Identität des Servers gelernt und authentifiziert, und der Server kann optional die Identität des Clients gelernt und authentifiziert haben. TLS unterstützt X.509-zertifikatbasierte [RFC5280] Server- und Client-Authentifizierung. Wenn ein PSK-Schlüsselaustausch verwendet wird (wie bei der Sitzungswiederaufnahme), wird die Kenntnis des PSK zur Authentifizierung des Peers verwendet.

Der TLS-Schlüsselaustausch ist resistent gegen Manipulation durch einen Angreifer, und das gemeinsame Geheimnis, das er produziert, kann von keinem teilnehmenden Peer kontrolliert werden.

TLS bietet zwei grundlegende Handshake-Modi, die für QUIC von Interesse sind:

  • Ein vollständiger 1-RTT-Handshake, bei dem der Client nach einem Roundtrip Anwendungsdaten senden kann und der Server sofort nach Erhalt der ersten Handshake-Nachricht des Clients antwortet.

  • Ein 0-RTT-Handshake, bei dem der Client Informationen verwendet, die er zuvor über den Server gelernt hat, um sofort Anwendungsdaten zu senden. Diese Anwendungsdaten können von einem Angreifer wiedergegeben werden, daher ist 0-RTT nicht geeignet für das Übertragen von Anweisungen, die beim Wiedergeben unerwünschte Konsequenzen haben könnten.

Abbildung 2 zeigt einen vereinfachten TLS-Handshake mit 0-RTT-Anwendungsdaten.

Client                                             Server

ClientHello
(0-RTT-Anwendungsdaten)  -------->
                                                     ServerHello
                                            {EncryptedExtensions}
                                                       {Finished}
                                    <--------   [Anwendungsdaten]
{Finished}                -------->

[Anwendungsdaten]         <------->   [Anwendungsdaten]

() Zeigt Nachrichten an, die durch frühe Datenschlüssel (0-RTT) geschützt sind
{} Zeigt Nachrichten an, die durch Handshake-Schlüssel geschützt sind
[] Zeigt Nachrichten an, die durch Anwendungsdatenschlüssel (1-RTT) geschützt sind

Abbildung 2: TLS-Handshake mit 0-RTT

Abbildung 2 lässt die EndOfEarlyData-Nachricht aus, die in QUIC nicht verwendet wird; siehe Abschnitt 8.3. Ebenso verwendet QUIC auch nicht die ChangeCipherSpec- oder KeyUpdate-Nachrichten. ChangeCipherSpec ist in TLS 1.3 redundant; siehe Abschnitt 8.4. QUIC hat seinen eigenen Schlüsselaktualisierungsmechanismus; siehe Abschnitt 6.

Daten werden mit mehreren Verschlüsselungsebenen geschützt:

  • Initiale Schlüssel (Initial keys)
  • Frühe Datenschlüssel (0-RTT) (Early data (0-RTT) keys)
  • Handshake-Schlüssel (Handshake keys)
  • Anwendungsdatenschlüssel (1-RTT) (Application data (1-RTT) keys)

Anwendungsdaten können nur auf den Ebenen für frühe Daten und Anwendungsdaten erscheinen. Handshake- und Alert-Nachrichten können auf jeder Ebene erscheinen.

Ein 0-RTT-Handshake kann verwendet werden, wenn Client und Server zuvor kommuniziert haben. Bei einem 1-RTT-Handshake kann der Client keine geschützten Anwendungsdaten senden, bis er alle vom Server gesendeten Handshake-Nachrichten erhalten hat.

Letztes Update am