Diagramme de la poignée de main TLS 1.3 : étape par étape, avec reprise de session et mTLS

Chaque requête HTTPS commence par une conversation que la plupart des ingénieurs ne regardent jamais. Avant que votre navigateur n'envoie GET /, lui et le serveur s'accordent sur une version de protocole, échangent des clés, vérifient un certificat et prouvent que personne n'a altéré quoi que ce soit. Quand cela se passe mal, vous obtenez des erreurs obscures comme handshake_failure ou bad_certificate, et quand c'est lent, chaque page en paie le prix.

TLS 1.3 a rendu la poignée de main plus courte et plus confidentielle que TLS 1.2. Cet article la parcourt message par message avec un diagramme de séquence, puis couvre les variantes que vous rencontrerez en production : HelloRetryRequest, reprise de session et 0-RTT, TLS mutuel, Encrypted Client Hello et échange de clés post-quantique.

Ce que la poignée de main doit accomplir

Une poignée de main TLS remplit quatre tâches avant que la moindre donnée applicative ne circule :

1. Négocier les paramètres : la version du protocole, la suite cryptographique et le groupe d'échange de clés.
2. Établir des clés partagées : les deux parties dérivent les mêmes secrets sans jamais les envoyer.
3. Authentifier le serveur, et éventuellement le client, au moyen de certificats.
4. Confirmer l'intégrité : les deux parties vérifient qu'elles ont vu les mêmes messages de poignée de main, pour qu'un attaquant ne puisse ni dégrader ni modifier la négociation.

La spécification actuelle est la RFC 9846, publiée en juillet 2026. Elle remplace la RFC 8446 mais conserve la même version de protocole : un client TLS 1.3 construit d'après l'ancienne RFC dialogue donc toujours avec un serveur construit d'après la nouvelle.

La poignée de main complète, message par message

TLS 1.3 n'a besoin que d'un aller-retour. Le client devine quel échange de clés le serveur acceptera et envoie sa moitié de l'échange dès le tout premier message.

La ligne importante est celle qui suit ServerHello. Dès que le client a la key share du serveur, les deux parties exécutent le key schedule (HKDF sur le secret partagé et la transcription) et dérivent les clés de trafic de la poignée de main. À partir de là, chaque message de la poignée de main est chiffré. En TLS 1.2, un observateur sur le réseau pouvait lire le certificat du serveur ; en TLS 1.3, il ne le peut pas.

CertificateVerify prouve que le serveur détient la clé privée du certificat qu'il vient d'envoyer. Finished prouve que les deux parties ont vu les mêmes messages. Si un attaquant retirait une suite cryptographique du ClientHello, les transcriptions différeraient et la vérification de Finished échouerait.

Le serveur peut envoyer des données applicatives juste après son Finished, et le client envoie sa première requête immédiatement après le sien. Un aller-retour après le ClientHello, la connexion chiffrée est prête.

Ce qui a changé depuis TLS 1.2

La liste des suites s'est réduite à TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256 et deux suites CCM. Une suite cryptographique TLS 1.3 ne nomme plus que le chiffrement des enregistrements et le hachage ; l'échange de clés et l'algorithme de signature se négocient séparément. Les certificats RSA fonctionnent toujours. Ce qui a disparu, c'est le transport de clé RSA, où le client chiffrait le secret avec la clé publique du serveur et où une clé volée déchiffrait chaque session enregistrée.

Quand un aller-retour en devient deux : HelloRetryRequest

La poignée de main en un aller-retour repose sur une supposition. Le client envoie des key shares pour les groupes qu'il s'attend à voir acceptés par le serveur, généralement X25519. Si le serveur n'en prend en charge aucun, il répond par un HelloRetryRequest qui nomme un groupe qu'il accepte, et le client recommence avec un nouveau ClientHello. Cela coûte un aller-retour complet de plus.

Vous le voyez quand un client et un serveur ne s'entendent pas sur les groupes, par exemple un serveur configuré uniquement pour P-256 et un client qui n'envoie qu'une share X25519. La solution est une question de configuration : assurez-vous que les groupes que vos clients proposent en premier sont ceux que vos serveurs préfèrent.

Reprise de session et 0-RTT

Après la poignée de main, le serveur peut envoyer des messages NewSessionTicket. Un ticket permet au client de reprendre plus tard avec une clé pré-partagée (PSK) au lieu d'un échange complet de certificats. La reprise exécute normalement quand même un nouvel échange (EC)DHE, si bien que la session reprise conserve la confidentialité persistante.

Avec un ticket, le client peut aussi envoyer des données précoces, appelées 0-RTT : la première requête voyage dans le même vol que le ClientHello. Cela économise un aller-retour, mais la RFC 9846 précise explicitement que les données 0-RTT n'ont aucune garantie contre le rejeu entre connexions. Un attaquant qui capture le premier vol peut le renvoyer.

Les règles pratiques :

• N'envoyez en données précoces que des requêtes idempotentes : un GET sans effet de bord, jamais un paiement ni une commande.
• Côté serveur, n'activez le 0-RTT que là où l'application peut rejeter ou tolérer les rejeux. Beaucoup de serveurs marquent les requêtes en données précoces (par exemple avec l'en-tête Early-Data: 1 défini dans la RFC 8470), pour que l'application puisse répondre 425 Too Early.
• N'utilisez pas le 0-RTT pour des actions authentifiées sans avoir réfléchi au rejeu.

TLS mutuel

En TLS mutuel (mTLS), le serveur demande aussi un certificat au client. Le serveur ajoute un CertificateRequest après EncryptedExtensions, et le client répond avec ses propres Certificate et CertificateVerify avant son Finished. Le nombre d'allers-retours ne change pas.

Le mTLS est la norme entre services dans un mesh : chaque workload reçoit un certificat de courte durée, et des sidecars ou des proxys gèrent la poignée de main. Le diagramme d'architecture d'un service mesh montre d'où viennent ces certificats, et le diagramme d'architecture zero trust explique pourquoi l'identité par requête compte davantage que le réseau d'où vient la requête.

Confidentialité et clés post-quantiques : les nouveautés de 2026

Deux RFC récentes changent l'apparence de la poignée de main sur le réseau.

Encrypted Client Hello. Le ClientHello est envoyé avant qu'aucune clé n'existe, donc le SNI, le nom d'hôte que veut le client, circule en clair. La RFC 9849, publiée en mars 2026, définit Encrypted Client Hello (ECH) : le client chiffre un ClientHello interne, qui contient le vrai nom d'hôte, avec une clé que le serveur publie dans le DNS. Les observateurs ne voient qu'un nom externe public, généralement celui d'un grand fournisseur.

Échange de clés hybride post-quantique. Le trafic enregistré aujourd'hui pourrait être déchiffré plus tard par un ordinateur quantique, c'est donc l'échange de clés qui évolue en premier. La RFC 10024, publiée en août 2026, définit des hybrides comme X25519MLKEM768, qui combine X25519 et ML-KEM-768. Les deux shares alimentent le key schedule, si bien que la connexion reste sûre tant que l'un des deux algorithmes tient. Chrome et Edge à partir de la version 131, ainsi que Firefox à partir de la version 132, le proposent par défaut.

Le prix, c'est la taille. Une share client X25519MLKEM768 fait 1 216 octets et la share serveur 1 120 octets, contre 32 octets chacune pour X25519 seul. Un ClientHello peut désormais s'étendre sur deux paquets, ce qui a révélé des middleboxes qui supposaient que cela n'arriverait jamais.

Le coût en allers-retours

Ce sont les allers-retours, pas la bande passante, qui déterminent la vitesse à laquelle une connexion est prête. Avec un aller-retour de 100 ms entre le client et le serveur, sans compter le DNS :

QUIC transporte la même poignée de main TLS 1.3 dans ses propres paquets (RFC 9001) et la fusionne avec la poignée de main de transport : c'est là que disparaît l'aller-retour supplémentaire. Terminer TLS près des utilisateurs, sur un CDN ou un répartiteur de charge en périphérie, raccourcit l'aller-retour lui-même ; le diagramme de répartiteur de charge montre où se fait habituellement la terminaison.

Le diagramme de la poignée de main

Comment le lire :

• Deux lignes de vie. Le client à gauche, le serveur à droite. Le temps s'écoule vers le bas.
• Les flèches simples sont envoyées en clair : ClientHello et ServerHello. Tout ce qui se trouve sous la ligne marquée « handshake keys » est chiffré.
• Le vol du serveur transporte EncryptedExtensions, Certificate, CertificateVerify et Finished d'un seul coup, c'est pourquoi la poignée de main tient en un aller-retour.
• Le fragment optionnel contient les Certificate et CertificateVerify du client, envoyés uniquement en TLS mutuel. Le CertificateRequest en pointillé dans le vol du serveur est ce qui les demande.
• Le bloc Markdown liste les extensions qui décident de la réussite de la poignée de main : versions, groupes, algorithmes de signature, SNI et ALPN.

Dessiner des diagrammes de protocole qui servent au débogage

• Marquez la frontière du chiffrement. La question la plus fréquente sur TLS est de savoir ce qu'un observateur peut voir. Tracez la ligne.
• Nommez les extensions qui comptent, pas toutes. key_share et supported_versions expliquent la plupart des échecs.
• Placez les chemins optionnels et alternatifs dans des fragments. Un fragment opt pour les certificats client et un fragment alt pour HelloRetryRequest gardent le flux principal lisible.
• Un diagramme par question. Une poignée de main complète, une reprise avec 0-RTT et un échange mTLS font trois diagrammes si chacun demande du détail.

L'exemple de diagramme de séquence traite plus en profondeur des lignes de vie, des fragments et des conventions de nommage.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez deux nœuds Ligne de vie du pack Séquence, nommés Client et Server.
3. Dessinez les messages comme des arêtes entre les lignes de vie, de haut en bas : ClientHello, ServerHello, puis les quatre messages chiffrés du serveur et le Finished du client. Étiquetez chaque arête avec le nom du message et ses champs clés.
4. Ajoutez un Fragment combiné du pack Séquence avec l'opérateur opt autour des Certificate et CertificateVerify du client, et dessinez le CertificateRequest du serveur comme une arête en pointillé.
5. Ajoutez un bloc Markdown du pack Base avec les extensions et le nombre d'allers-retours, et une Note qui marque l'endroit où commence le chiffrement.

L'exemple utilise 4 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Combien d'allers-retours prend une poignée de main TLS 1.3 ? Un pour une nouvelle connexion, contre deux en TLS 1.2. Un HelloRetryRequest en ajoute un second, et la reprise 0-RTT permet au client d'envoyer sa première requête sans aucun aller-retour de poignée de main.

Le certificat du serveur est-il chiffré en TLS 1.3 ? Oui. Tout ce qui suit ServerHello, y compris le message Certificate, est chiffré avec les clés de poignée de main. Le ClientHello ne l'est pas : c'est la brèche que comble Encrypted Client Hello.

Le 0-RTT est-il sûr à activer ? Seulement pour les requêtes qui peuvent être rejouées sans risque. Les données précoces peuvent être capturées et renvoyées, alors limitez-les aux requêtes idempotentes et laissez l'application rejeter tout le reste avec 425 Too Early.

TLS 1.3 prend-il encore en charge les certificats RSA ? Oui. Les signatures RSA servent toujours à authentifier les serveurs. TLS 1.3 a supprimé le transport de clé RSA, où le secret de session était chiffré avec la clé RSA du serveur et où une clé divulguée exposait le trafic passé.

Quelle est la différence entre TLS et mTLS ? En TLS classique, seul le serveur présente un certificat. En TLS mutuel, le serveur demande aussi un certificat au client, si bien que les deux parties s'authentifient dans la même poignée de main.

Commencez gratuitement — un siège, sans carte bancaire.