La poignée de main TLS 1.3, en résumé

Ce que c'est

La RFC 8446 définit la poignée de main. Le client envoie un ClientHello avec les extensions supported_versions, signature_algorithms et key_share ; le partage de clé est une valeur publique (EC)DHE éphémère pour un ou plusieurs groupes. Le serveur choisit un groupe et répond par un ServerHello portant son propre key_share. Les deux parties dérivent alors des clés de poignée de main, et tout message suivant est chiffré : EncryptedExtensions, le Certificate et le CertificateVerify du serveur (une signature portant sur la transcription), et Finished (un HMAC portant sur la transcription). Le client répond avec son propre Finished et peut ensuite envoyer des données applicatives. Un seul aller-retour, d'où « 1-RTT ». Si le client a deviné un groupe que le serveur ne prend pas en charge, le serveur envoie HelloRetryRequest et le client retente avec un partage de clé différent, ce qui coûte un aller-retour supplémentaire.

Après la poignée de main, le serveur peut envoyer des messages NewSessionTicket ; une connexion ultérieure présente le ticket comme pre_shared_key et peut ainsi éviter l'échange de certificat. Avec une telle PSK, le client peut aussi envoyer des « données précoces » (0-RTT) dans son premier envoi. La RFC indique clairement que les données 0-RTT n'offrent pas de confidentialité persistante (forward secrecy) et qu'il n'existe aucune garantie de non-rejeu entre les connexions.

Pourquoi c'est important

La RFC 8446 énumère ce qui a été supprimé par rapport à TLS 1.2 : les suites de chiffrement RSA statique et Diffie-Hellman (transport de clé RSA), la compression, DSA, les groupes DHE personnalisés et les chiffrements symétriques hérités ; la renégociation est purement et simplement interdite. Chaque échange de clé à clé publique offre désormais une confidentialité persistante, et chaque suite restante est de type AEAD (TLS_AES_128_GCM_SHA256 est obligatoire à implémenter). Le certificat n'est plus visible sur le fil, ce qui change ce que les boîtiers intermédiaires passifs et la journalisation peuvent observer.

Comment l'appliquer

• Préférer TLS 1.3 partout où les deux extrémités le prennent en charge ; la version est négociée via supported_versions, et non via le champ de version hérité, si bien que les anciens boîtiers intermédiaires qui inspectent ce champ voient toujours « TLS 1.2 ».
• Proposer en premier le groupe de partage de clé préféré des pairs attendus, afin d'éviter les allers-retours dus à HelloRetryRequest ; la RFC impose secp256r1 et recommande X25519 pour les clients.
• Laisser 0-RTT désactivé, sauf si la couche applicative n'envoie que des requêtes idempotentes en phase précoce ; la section anti-rejeu de la RFC décrit les tickets à usage unique et les contrôles de fraîcheur qu'un serveur devrait mettre en œuvre.
• Préférer la reprise avec un partage de clé frais (psk_dhe_ke) : la RFC indique qu'une PSK utilisée seule fait perdre la confidentialité persistante pour les données applicatives, de sorte qu'une clé de ticket compromise exposerait ces sessions. Faire tourner les clés de ticket dans tous les cas.

Pièges

Le « mode de compatibilité avec les boîtiers intermédiaires » fait ressembler TLS 1.3, sur le fil, à une reprise de session TLS 1.2 ; les captures de paquets ont donc besoin des secrets de session, et non du seul certificat, pour être déchiffrées. Les certificats client fonctionnent toujours, mais sont demandés à l'intérieur de la partie chiffrée de la poignée de main, si bien que les mandataires qui terminent TLS doivent les gérer eux-mêmes.