Aller au contenu principal

3.1. Vue d'ensemble

Le client indique qu'il prend en charge ce mécanisme en incluant une extension TLS SessionTicket dans le message ClientHello. L'extension sera vide si le client ne possède pas déjà un ticket pour le serveur. Le serveur envoie une extension SessionTicket vide pour indiquer qu'il enverra un nouveau ticket de session à l'aide du message de handshake NewSessionTicket. L'extension est décrite à la section 3.2.

Si le serveur souhaite utiliser ce mécanisme, il stocke son état de session (tel que la suite de chiffrement (ciphersuite) et le secret maître (master secret)) dans un ticket qui est chiffré et protégé en intégrité par une clé connue uniquement du serveur. Le ticket est distribué au client à l'aide du message de handshake TLS NewSessionTicket décrit à la section 3.3. Ce message est envoyé pendant le handshake TLS avant le message ChangeCipherSpec, après que le serveur a vérifié avec succès le message Finished du 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

Figure 1 : Flux de messages pour un handshake complet émettant un nouveau ticket de session

Le client met en cache ce ticket avec le secret maître (master secret) et les autres paramètres associés à la session en cours. Lorsque le client souhaite reprendre la session, il inclut le ticket dans l'extension SessionTicket du message ClientHello. L'annexe A fournit une description détaillée de l'encodage de l'extension et des changements par rapport à la RFC 4507. Le serveur déchiffre ensuite le ticket reçu, vérifie la validité du ticket, récupère l'état de session à partir du contenu du ticket et utilise cet état pour reprendre la session. L'interaction avec le TLS Session ID est décrite à la section 3.4. Si le serveur vérifie avec succès le ticket du client, il peut alors renouveler le ticket en incluant un message de handshake NewSessionTicket après le ServerHello.

      Client                                                Server
ClientHello
(SessionTicket extension) -------->
ServerHello
(empty SessionTicket extension)
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data

Figure 2 : Flux de messages pour un handshake abrégé utilisant un nouveau ticket de session

Un format de ticket recommandé est donné à la section 4.

Si le serveur ne peut pas ou ne souhaite pas honorer le ticket, il peut alors initier un handshake complet avec le client.

Dans le cas où le serveur ne souhaite pas émettre un nouveau ticket à ce moment, il termine simplement le handshake sans inclure d'extension SessionTicket ni de message de handshake NewSessionTicket. Cela est illustré ci-dessous (ce flux est identique à la figure 1 de la RFC 4346, à l'exception de l'extension SessionTicket dans le premier message) :

  Client                                               Server
      ClientHello
(SessionTicket extension) -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data

Figure 3 : Flux de messages pour un serveur effectuant un handshake complet sans émettre de nouveau ticket de session

Il est également permis d'avoir un échange similaire à la figure 3 en utilisant le handshake abrégé défini dans la figure 2 de la RFC 4346, où le client utilise l'extension SessionTicket pour reprendre la session, mais où le serveur ne souhaite pas émettre un nouveau ticket, et donc n'envoie pas d'extension SessionTicket.

Si le serveur rejette le ticket, il peut néanmoins souhaiter émettre un nouveau ticket après avoir effectué le handshake complet, comme illustré ci-dessous (ce flux est identique à la figure 1, à l'exception du fait que l'extension SessionTicket dans le ClientHello n'est pas vide) :

  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

Figure 4 : Flux de messages pour un serveur rejetant le ticket, effectuant un handshake complet et émettant un nouveau ticket de session