Passa al contenuto principale

3. Protocollo

Questa specifica descrive un meccanismo per distribuire informazioni sullo stato della sessione crittografate al client sotto forma di ticket e un meccanismo per presentare il ticket al server. Il ticket viene creato da un server TLS e inviato a un client TLS. Il client TLS presenta il ticket al server TLS per ripristinare una sessione. Le implementazioni di questa specifica dovrebbero supportare entrambi i meccanismi. Altre specifiche possono trarre vantaggio dai ticket di sessione, eventualmente specificando mezzi alternativi per la distribuzione o la selezione. Ad esempio, una specifica separata può descrivere un modo alternativo per distribuire un ticket e utilizzare l'estensione TLS in questo documento per ripristinare la sessione. Questo comportamento è al di fuori dell'ambito del documento e dovrebbe essere descritto in una specifica separata.

3.1. Panoramica

Il client indica che supporta questo meccanismo includendo un'estensione TLS SessionTicket nel messaggio ClientHello. L'estensione sarà vuota se il client non possiede ancora un ticket per il server. Il server invia un'estensione SessionTicket vuota per indicare che invierà un nuovo ticket di sessione utilizzando il messaggio di handshake NewSessionTicket. L'estensione è descritta nella Sezione 3.2.

Se il server desidera utilizzare questo meccanismo, memorizza il suo stato di sessione (come suite di cifratura e master secret) in un ticket che è crittografato e protetto in integrità da una chiave nota solo al server. Il ticket viene distribuito al client utilizzando il messaggio di handshake TLS NewSessionTicket descritto nella Sezione 3.3. Questo messaggio viene inviato durante l'handshake TLS prima del messaggio ChangeCipherSpec, dopo che il server ha verificato con successo il messaggio Finished del client.

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

Figura 1: Flusso di messaggi per handshake completo che emette un nuovo ticket di sessione

Il client memorizza nella cache questo ticket insieme al master secret e altri parametri associati alla sessione corrente. Quando il client desidera ripristinare la sessione, include il ticket nell'estensione SessionTicket all'interno del messaggio ClientHello. L'Appendice A fornisce una descrizione dettagliata della codifica dell'estensione e delle modifiche rispetto a RFC 4507. Il server quindi decrittografa il ticket ricevuto, verifica la validità del ticket, recupera lo stato della sessione dal contenuto del ticket e utilizza questo stato per ripristinare la sessione. L'interazione con l'ID di sessione TLS è descritta nella Sezione 3.4. Se il server verifica con successo il ticket del client, può rinnovare il ticket includendo un messaggio di handshake NewSessionTicket dopo il ServerHello.

3.2. Estensione TLS SessionTicket

L'estensione TLS SessionTicket si basa su [RFC4366]. Il formato del ticket è una struttura opaca utilizzata per trasportare informazioni sullo stato specifico della sessione. Questa estensione può essere inviata nel ClientHello e ServerHello.

3.3. Messaggio di handshake NewSessionTicket

Questo messaggio viene inviato dal server durante l'handshake TLS prima del messaggio ChangeCipherSpec. Questo messaggio DEVE essere inviato se il server ha incluso un'estensione SessionTicket nel ServerHello.

3.4. Interazione con l'ID di sessione TLS

Se un server sta pianificando di emettere un NewSessionTicket, DOVREBBE includere un ID di sessione vuoto nel ServerHello. Se il server include un ID di sessione non vuoto, sta indicando l'intenzione di utilizzare il ripristino della sessione con stato.