2. Protocol Overview (Vue d'ensemble du protocole)
Les paramètres cryptographiques utilisés par le canal sécurisé sont produits par le protocole de négociation TLS (Handshake Protocol). Ce sous-protocole de TLS est utilisé lorsque le client et le serveur communiquent pour la première fois. Le protocole de négociation permet aux pairs de négocier une version de protocole, sélectionner des algorithmes cryptographiques, s'authentifier mutuellement de manière optionnelle, et établir le matériel de clé secrète partagé. Une fois la négociation terminée, les pairs utilisent les clés établies pour protéger le trafic de la couche application.
Un échec de la négociation ou une autre erreur de protocole déclenche la terminaison de la connexion, précédée optionnellement par un message d'alerte (Alert Message) (Section 6).
TLS supporte trois modes d'échange de clés de base (Key Exchange Modes):
- (EC)DHE (Diffie-Hellman sur des corps finis ou des courbes elliptiques)
- PSK-only (clé pré-partagée uniquement)
- PSK with (EC)DHE (clé pré-partagée avec (EC)DHE)
La figure 1 ci-dessous montre la négociation TLS complète de base:
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]
+ Indique les extensions notables envoyées dans le
message précédemment mentionné.
* Indique les messages/extensions optionnels ou
dépendants de la situation qui ne sont pas toujours envoyés.
{} Indique les messages protégés à l'aide de clés
dérivées d'un [sender]_handshake_traffic_secret.
[] Indique les messages protégés à l'aide de clés
dérivées de [sender]_application_traffic_secret_N.
Figure 1: Flux de messages pour la négociation TLS complète
La négociation peut être considérée comme ayant trois phases (indiquées dans le diagramme ci-dessus):
-
Key Exchange (Échange de clés): Établir le matériel de clé partagé et sélectionner les paramètres cryptographiques. Tout après cette phase est chiffré.
-
Server Parameters (Paramètres du serveur): Établir d'autres paramètres de négociation (si le client est authentifié, support du protocole de couche application, etc.).
-
Authentication (Authentification): Authentifier le serveur (et optionnellement le client) et fournir la confirmation de clé et l'intégrité de la négociation.
Dans la phase Key Exchange, le client envoie le message ClientHello (Section 4.1.2), qui contient un nonce aléatoire (ClientHello.random); ses versions de protocole proposées; une liste de paires cipher/hash HKDF symétriques; soit un ensemble de partages de clés Diffie-Hellman (dans l'extension "key_share" (Section 4.2.8)), un ensemble d'étiquettes de clés pré-partagées (dans l'extension "pre_shared_key" (Section 4.2.11)), ou les deux; et potentiellement des extensions supplémentaires. Des champs et/ou messages supplémentaires peuvent également être présents pour la compatibilité avec les middleboxes.
Le serveur traite le ClientHello et détermine les paramètres cryptographiques appropriés pour la connexion. Il répond ensuite avec son propre ServerHello (Section 4.1.3), qui indique les paramètres de connexion négociés. La combinaison du ClientHello et du ServerHello détermine les clés partagées. Si l'établissement de clés (EC)DHE est utilisé, alors le ServerHello contient une extension "key_share" avec le partage Diffie-Hellman éphémère du serveur; le partage du serveur DOIT être dans le même groupe que l'un des partages du client. Si l'établissement de clés PSK est utilisé, alors le ServerHello contient une extension "pre_shared_key" indiquant lequel des PSK offerts par le client a été sélectionné. Notez que les implémentations peuvent utiliser (EC)DHE et PSK ensemble, auquel cas les deux extensions seront fournies.
Le serveur envoie ensuite deux messages pour établir les Server Parameters:
EncryptedExtensions: Réponses aux extensions ClientHello qui ne sont pas nécessaires pour déterminer les paramètres cryptographiques, autres que celles spécifiques aux certificats individuels. [Section 4.3.1]
CertificateRequest: Si l'authentification client basée sur certificat est souhaitée, les paramètres souhaités pour ce certificat. Ce message est omis si l'authentification client n'est pas souhaitée. [Section 4.3.2]
Enfin, le client et le serveur échangent des messages d'Authentication. TLS utilise le même ensemble de messages chaque fois que l'authentification basée sur certificat est nécessaire. (L'authentification basée sur PSK se produit comme un effet secondaire de l'échange de clés.) Spécifiquement:
Certificate: Le certificat du point d'extrémité et toutes les extensions par certificat. Ce message est omis par le serveur s'il ne s'authentifie pas avec un certificat et par le client si le serveur n'a pas envoyé de CertificateRequest (indiquant ainsi que le client ne devrait pas s'authentifier avec un certificat). Notez que si les clés publiques brutes [RFC7250] ou l'extension d'informations en cache [RFC7924] sont utilisées, alors ce message ne contiendra pas de certificat mais plutôt une autre valeur correspondant à la clé à long terme du serveur. [Section 4.4.2]
CertificateVerify: Une signature sur l'ensemble de la négociation utilisant la clé privée correspondant à la clé publique du message Certificate. Ce message est omis si le point d'extrémité ne s'authentifie pas via un certificat. [Section 4.4.3]
Finished: Un MAC (Message Authentication Code) sur l'ensemble de la négociation. Ce message fournit la confirmation de clé, lie l'identité du point d'extrémité aux clés échangées, et en mode PSK authentifie également la négociation. [Section 4.4.4]
Après réception des messages du serveur, le client répond avec ses messages d'authentification, à savoir Certificate et CertificateVerify (si demandés), et Finished.
À ce stade, la négociation est terminée, et le client et le serveur dérivent le matériel de clé requis par la couche d'enregistrement pour échanger des données de couche application protégées via le chiffrement authentifié. Les Application Data NE DOIVENT PAS être envoyées avant l'envoi du message Finished, sauf comme spécifié dans la Section 2.3. Notez que bien que le serveur puisse envoyer des Application Data avant de recevoir les messages d'authentification du client, toutes les données envoyées à ce moment sont, bien sûr, envoyées à un pair non authentifié.
2.1 Incorrect DHE Share (Partage DHE incorrect)
Si le client n'a pas fourni une extension "key_share" suffisante (par exemple, il n'inclut que des groupes DHE ou ECDHE inacceptables ou non supportés par le serveur), le serveur corrige l'inadéquation avec un HelloRetryRequest et le client doit redémarrer la négociation avec une extension "key_share" appropriée, comme montré dans la Figure 2. Si aucun paramètre cryptographique commun ne peut être négocié, le serveur DOIT abandonner la négociation avec une alerte appropriée.
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]
Figure 2: Flux de messages pour une négociation complète avec
des paramètres incompatibles
Note: La transcription de négociation (Handshake Transcript) inclut l'échange initial ClientHello/HelloRetryRequest; elle n'est pas réinitialisée avec le nouveau ClientHello.
TLS permet également plusieurs variantes optimisées de la négociation de base, comme décrit dans les sections suivantes.
2.2 Resumption and Pre-Shared Key (PSK) (Reprise et clé pré-partagée)
Bien que les PSK TLS puissent être établis hors bande, les PSK peuvent également être établis dans une connexion précédente puis utilisés pour établir une nouvelle connexion ("reprise de session (Session Resumption)" ou "reprise" utilisant un PSK). Une fois qu'une négociation est terminée, le serveur peut envoyer au client une identité PSK (PSK Identity) qui correspond à une clé unique dérivée de la négociation initiale (voir Section 4.6.1). Le client peut ensuite utiliser cette identité PSK dans de futures négociations pour négocier l'utilisation du PSK associé. Si le serveur accepte le PSK, alors le contexte de sécurité de la nouvelle connexion est cryptographiquement lié à la connexion originale et la clé dérivée de la négociation initiale est utilisée pour amorcer l'état cryptographique au lieu d'une négociation complète. Dans TLS 1.2 et versions antérieures, cette fonctionnalité était fournie par les "ID de session (Session IDs)" et les "tickets de session (Session Tickets)" [RFC5077]. Ces deux mécanismes sont obsolètes dans TLS 1.3.
Les PSK peuvent être utilisés avec l'échange de clés (EC)DHE afin de fournir la confidentialité persistante en combinaison avec des clés partagées, ou peuvent être utilisés seuls, au prix de la perte de la confidentialité persistante pour les données d'application.
La Figure 3 montre une paire de négociations dans laquelle la première établit un PSK et la seconde l'utilise:
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]
Figure 3: Flux de messages pour la reprise et PSK
Comme le serveur s'authentifie via un PSK, il n'envoie pas de message Certificate ou CertificateVerify. Lorsqu'un client offre la reprise via un PSK, il DEVRAIT également fournir une extension "key_share" au serveur pour permettre au serveur de décliner la reprise et de revenir à une négociation complète, si nécessaire. Le serveur répond avec une extension "pre_shared_key" pour négocier l'utilisation de l'établissement de clés PSK et peut (comme montré ici) répondre avec une extension "key_share" pour effectuer l'établissement de clés (EC)DHE, fournissant ainsi la confidentialité persistante.
Lorsque les PSK sont provisionnés hors bande, l'identité PSK et l'algorithme de hachage KDF à utiliser avec le PSK DOIVENT également être provisionnés.
Note: Lors de l'utilisation d'un secret pré-partagé provisionné hors bande, une considération critique est d'utiliser une entropie suffisante lors de la génération de clés, comme discuté dans [RFC4086]. Dériver un secret partagé d'un mot de passe ou d'autres sources de faible entropie n'est pas sécurisé. Un secret de faible entropie, ou mot de passe, est sujet aux attaques par dictionnaire basées sur le liant PSK (PSK Binder). L'authentification PSK spécifiée n'est pas un échange de clés authentifié basé sur un mot de passe fort même lorsqu'elle est utilisée avec l'établissement de clés Diffie-Hellman. Spécifiquement, elle n'empêche pas un attaquant qui peut observer la négociation d'effectuer une attaque par force brute sur le mot de passe/clé pré-partagée.
2.3 0-RTT Data (Données 0-RTT)
Lorsque les clients et serveurs partagent un PSK (obtenu soit de manière externe, soit via une négociation précédente), TLS 1.3 permet aux clients d'envoyer des données lors de la première transmission ("données précoces (Early Data)"). Le client utilise le PSK pour authentifier le serveur et chiffrer les données précoces.
Comme montré dans la Figure 4, les données 0-RTT sont simplement ajoutées à la négociation 1-RTT lors de la première transmission. Le reste de la négociation utilise les mêmes messages que pour une négociation 1-RTT avec reprise PSK.
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]
+ Indique les extensions notables envoyées dans le
message précédemment mentionné.
* Indique les messages/extensions optionnels ou
dépendants de la situation qui ne sont pas toujours envoyés.
() Indique les messages protégés à l'aide de clés
dérivées d'un client_early_traffic_secret.
{} Indique les messages protégés à l'aide de clés
dérivées d'un [sender]_handshake_traffic_secret.
[] Indique les messages protégés à l'aide de clés
dérivées de [sender]_application_traffic_secret_N.
Figure 4: Flux de messages pour une négociation 0-RTT
NOTE IMPORTANTE: Les propriétés de sécurité des données 0-RTT sont plus faibles que celles des autres types de données TLS. Spécifiquement:
-
Ces données ne sont pas à confidentialité persistante (Forward Secret), car elles sont chiffrées uniquement sous des clés dérivées du PSK offert.
-
Il n'y a aucune garantie de non-rejeu (Non-Replay) entre les connexions. La protection contre le rejeu pour les données TLS 1.3 1-RTT ordinaires est fournie via la valeur Random du serveur, mais les données 0-RTT ne dépendent pas du ServerHello et ont donc des garanties plus faibles. Ceci est particulièrement pertinent si les données sont authentifiées avec l'authentification client TLS ou à l'intérieur du protocole d'application. Les mêmes avertissements s'appliquent à toute utilisation de l'early_exporter_master_secret.
Les données 0-RTT ne peuvent pas être dupliquées au sein d'une connexion (c'est-à-dire que le serveur ne traitera pas les mêmes données deux fois pour la même connexion), et un attaquant ne pourra pas faire apparaître les données 0-RTT comme des données 1-RTT (car elles sont protégées avec des clés différentes). L'Annexe E.5 contient une description des attaques potentielles, et la Section 8 décrit les mécanismes que le serveur peut utiliser pour limiter l'impact du rejeu.