La poignée de main TLS 1.3 en une page

Deux machines qui ne se sont jamais vues conviennent d’un secret sous les yeux de tout le réseau, en un seul aller-retour, et sans que ce secret circule jamais : c’est plus de discrétion qu’on n’en obtient d’un dîner de famille.

L’essentiel

• TLS 1.3 est défini par la RFC 8446 (2018). La poignée de main nominale tient en un aller-retour (1-RTT) : le client envoie sa part de clé dès le premier message, sans attendre qu’on la lui demande.
• Dans une poignée de main complète, l’échange de clé est toujours éphémère (ECDHE ou DHE) : voler plus tard la clé privée du serveur ne permet pas de déchiffrer les sessions enregistrées. C’est la confidentialité persistante, devenue obligatoire.
• Le certificat du serveur sert à prouver son identité, pas à chiffrer : le message CertificateVerify est une signature sur tout l’échange précédent, faite avec la clé privée du certificat.
• Tout ce qui suit le ServerHello est chiffré, certificat compris. En TLS 1.2, le certificat voyageait en clair.
• Les deux Finished scellent la conversation : chacun calcule une empreinte de tous les messages échangés, et une modification en route, même d’un Hello en clair, fait échouer la poignée de main.
• La version 1.3 a supprimé l’échange de clé par chiffrement RSA, les suites CBC, RC4, la compression et la renégociation. Il ne reste que des chiffrements authentifiés (AES-GCM, ChaCha20-Poly1305, AES-CCM).
• Si le serveur ne prend pas en charge le groupe de la clé envoyée, il répond par un HelloRetryRequest et la poignée de main coûte un aller-retour de plus.
• Le 0-RTT, permis lors d’une reprise de session, envoie des données avec le premier message. Ces données peuvent être rejouées par un attaquant : on les réserve aux requêtes sans effet de bord (HTTP prévoit pour cela le code 425 Too Early, RFC 8470).

Idées reçues, et fausses

• « Le cadenas veut dire que le site est honnête. » Faux. Il veut dire que la connexion est chiffrée vers un serveur qui contrôle ce nom de domaine. Un certificat s’obtient gratuitement en quelques minutes, et les sites d’hameçonnage en ont, eux aussi : le cadenas certifie l’adresse de l’escroc, pas sa moralité.
• « TLS cache le site que je visite. » Faux. Le nom du site part en clair dans le ClientHello (l’extension SNI), sans compter la requête DNS qui l’a précédé et l’adresse IP de destination. Seule l’extension ECH (Encrypted Client Hello), quand le navigateur et le serveur la prennent en charge, chiffre ce nom ; l’adresse IP, elle, reste visible.
• « TLS 1.3, c’est TLS 1.2 en plus rapide. » Faux. C’est surtout TLS 1.2 avec moins d’options dangereuses : plus d’échange de clé par RSA ni de Diffie-Hellman statique, plus de suites CBC, un certificat chiffré, une poignée de main signée de bout en bout.
• « Chiffré, donc personne ne lit. » Faux. Les deux extrémités lisent, par construction. Un proxy d’inspection d’entreprise lit aussi, puisqu’il présente ses propres certificats signés par une autorité installée sur les postes. Et une application qui ne vérifie pas le certificat chiffre avec soin sa conversation avec n’importe qui.
• « Le 0-RTT, c’est la même chose, en plus rapide. » Faux. C’est plus rapide parce qu’on a retiré une protection : les données précoces ne sont pas protégées contre le rejeu. Un virement envoyé en 0-RTT peut être exécuté deux fois, ce qui réjouit rarement les deux parties.

Pour aller plus loin : Comprendre TLS : mécanismes, garanties et limites · Sécuriser un canal : TLS, HTTPS et mTLS · Établir une clé : Diffie-Hellman, KEM et HPKE · QUIC, HTTP moderne, TLS et proxys applicatifs · Migrer TLS legacy sans casser les clients anciens · Intégrer la cryptographie post-quantique dans TLS · Attaque de l’intercepteur et proxy TLS · Pare-feu, architectures et NAT en une page.

À lire aussi

• Suivre un flux de bout en boutApprendre à raconter un échange complet depuis une action utilisateur jusqu’au service distant, en distinguant nom, adresse, chemin, transport, chiffrement et réponse applicative.
• DNSSEC, DoH, DoT, ODoH et perte de visibilité pour la défenseComparaison de DNSSEC, DoT, DoH, DoQ et ODoH, ce que chacun protège et contre qui, ce que la résolution chiffrée retire à la détection et comment la défense reprend la main.
• DNS over TLS (DoT) : chiffrer la résolution de nomsLe DNS over TLS (DoT, RFC 7858) chiffre les requêtes DNS via le protocole TLS pour protéger la confidentialité et l'intégrité de la résolution de noms.

Pages voisines

La poignée de main TLS 1.3 en une page

Elle cite

• ⇄Lien dans les deux sens :Pare-feu, architectures et NAT en une page
• Attaque de l'intercepteur par ARP, DHCP, DNS, Wi-Fi et proxy TLS
• Comprendre TLS : mécanismes, garanties et limites
• Établir une clé : Diffie-Hellman, KEM et HPKE
• Intégrer la cryptographie post-quantique dans TLS
• Migrer TLS legacy sans casser les clients anciens
• QUIC, HTTP moderne, TLS et proxys applicatifs
• Sécuriser un canal: TLS, HTTPS et mTLS

⇄ : les deux pages se citent l’une l’autre.