3.1. Überblick
Der Client zeigt an, dass er diesen Mechanismus unterstützt, indem er eine SessionTicket TLS-Erweiterung in die ClientHello-Nachricht aufnimmt. Die Erweiterung ist leer, wenn der Client noch kein Ticket für den Server besitzt. Der Server sendet eine leere SessionTicket-Erweiterung, um anzuzeigen, dass er ein neues Sitzungsticket unter Verwendung der NewSessionTicket-Handshake-Nachricht senden wird. Die Erweiterung ist in Abschnitt 3.2 beschrieben.
Wenn der Server diesen Mechanismus verwenden möchte, speichert er seinen Sitzungszustand (etwa Ciphersuite und Master-Secret (master secret)) in einem Ticket, das mit einem nur dem Server bekannten Schlüssel verschlüsselt und integritätsgeschützt wird. Das Ticket wird an den Client unter Verwendung der in Abschnitt 3.3 beschriebenen TLS-Handshake-Nachricht NewSessionTicket verteilt. Diese Nachricht wird während des TLS-Handshakes vor der ChangeCipherSpec-Nachricht gesendet, nachdem der Server die Finished-Nachricht des Clients erfolgreich verifiziert hat.
Client Server
ClientHello
(empty SessionTicket extension)-------->
ServerHello
(empty SessionTicket extension)
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Abbildung 1: Nachrichtenfluss für einen vollständigen Handshake, der ein neues Sitzungsticket ausstellt
Der Client speichert dieses Ticket zusammen mit dem Master-Secret und anderen der aktuellen Sitzung zugeordneten Parametern zwischen. Wenn der Client die Sitzung wiederaufnehmen möchte, nimmt er das Ticket in die SessionTicket-Erweiterung innerhalb der ClientHello-Nachricht auf. Anhang A liefert eine detaillierte Beschreibung der Kodierung der Erweiterung und der Änderungen gegenüber RFC 4507. Der Server entschlüsselt dann das empfangene Ticket, verifiziert die Gültigkeit des Tickets, ruft den Sitzungszustand aus dem Inhalt des Tickets ab und verwendet diesen Zustand, um die Sitzung wiederaufzunehmen. Die Interaktion mit der TLS Session ID ist in Abschnitt 3.4 beschrieben. Wenn der Server das Ticket des Clients erfolgreich verifiziert, kann er das Ticket erneuern, indem er nach dem ServerHello eine NewSessionTicket-Handshake-Nachricht aufnimmt.
Client Server
ClientHello
(SessionTicket extension) -------->
ServerHello
(empty SessionTicket extension)
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
Abbildung 2: Nachrichtenfluss für einen verkürzten Handshake unter Verwendung eines neuen Sitzungstickets
Ein empfohlenes Ticket-Format ist in Abschnitt 4 angegeben.
Wenn der Server das Ticket nicht berücksichtigen kann oder will, kann er einen vollständigen Handshake mit dem Client initiieren.
Für den Fall, dass der Server zu diesem Zeitpunkt kein neues Ticket ausstellen möchte, schließt er den Handshake einfach ab, ohne eine SessionTicket-Erweiterung oder eine NewSessionTicket-Handshake-Nachricht aufzunehmen. Dies ist unten dargestellt (dieser Ablauf ist mit Abbildung 1 in RFC 4346 identisch, mit Ausnahme der SessionTicket-Erweiterung in der ersten Nachricht):
Client Server
ClientHello
(SessionTicket extension) -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Abbildung 3: Nachrichtenfluss für einen Server, der einen vollständigen Handshake abschließt, ohne ein neues Sitzungsticket auszustellen
Es ist außerdem zulässig, einen Austausch ähnlich Abbildung 3 unter Verwendung des in Abbildung 2 von RFC 4346 definierten verkürzten Handshakes durchzuführen, bei dem der Client die SessionTicket-Erweiterung verwendet, um die Sitzung wiederaufzunehmen, der Server aber kein neues Ticket ausstellen möchte und daher keine SessionTicket-Erweiterung sendet.
Wenn der Server das Ticket zurückweist, möchte er möglicherweise dennoch ein neues Ticket ausstellen, nachdem er den vollständigen Handshake durchgeführt hat, wie unten dargestellt (dieser Ablauf ist mit Abbildung 1 identisch, außer dass die SessionTicket-Erweiterung im ClientHello nicht leer ist):
Client Server
ClientHello
(SessionTicket extension) -------->
ServerHello
(empty SessionTicket extension)
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Abbildung 4: Nachrichtenfluss für einen Server, der das Ticket zurückweist, einen vollständigen Handshake durchführt und ein neues Sitzungsticket ausstellt