Expliquez-moi le handshake TLS 1.3.

Le handshake TLS 1.3 existe pour résoudre un problème : deux parties qui ne se sont jamais rencontrées doivent se mettre d'accord sur un secret partagé via un réseau qu'un attaquant peut lire, et elles doivent être sûres de parler à la bonne partie. Il y parvient en un seul aller-retour, ce qui constitue l'amélioration majeure par rapport à TLS 1.2.

Le déroulement, étape par étape

1. ClientHello. Le client ouvre la communication avec la version de TLS qu'il souhaite, un nonce aléatoire, les suites de chiffrement qu'il prend en charge, les groupes nommés (courbes elliptiques) sur lesquels il peut faire de l'ECDHE et, surtout, un key share : une clé publique éphémère pour un ou plusieurs de ces groupes. TLS 1.3 est tranché, donc le client suppose que le serveur acceptera l'un de ses shares.
2. ServerHello. Le serveur choisit une suite de chiffrement et un groupe, renvoie son propre key share éphémère, et les deux parties disposent désormais de tout ce qu'il faut pour calculer le même secret partagé via Diffie-Hellman.
3. Dérivation des clés. Les deux parties effectuent le calcul ECDHE et passent le résultat dans la fonction de dérivation de clés HKDF pour produire les clés de trafic. À partir de là, le reste du handshake est chiffré.
4. Authentification du serveur. Sous ce chiffrement, le serveur envoie son certificat et un CertificateVerify : une signature sur la transcription du handshake qui prouve qu'il détient la clé privée associée au certificat. Le client valide la chaîne de certificats jusqu'à une CA de confiance.
5. Finished. Les deux parties échangent un MAC sur l'ensemble de la transcription pour confirmer que rien n'a été altéré, et les données applicatives circulent.

Pourquoi c'est mieux que TLS 1.2

• Un aller-retour, pas deux. Comme le client envoie de manière spéculative un key share dans le premier message, le serveur peut répondre avec tout le nécessaire. TLS 1.2 nécessitait un aller-retour supplémentaire.
• La confidentialité persistante est obligatoire. TLS 1.3 a supprimé l'échange de clés RSA statique. Chaque session utilise des clés éphémères, de sorte que compromettre ultérieurement la clé à long terme du serveur ne permet pas à un attaquant de déchiffrer le trafic passé qu'il aurait capturé.
• Un menu de chiffrement plus restreint et plus sûr. Les options faibles et rarement correctes (RC4, MAC en mode CBC, renégociation, compression) ont été retirées, réduisant la surface d'attaque.

Le piège à surveiller

TLS 1.3 ajoute le 0-RTT (« early data »), où un client qui revient peut envoyer des données applicatives dès son tout premier message en utilisant une clé pré-partagée. C'est rapide, mais les données 0-RTT sont rejouables par un attaquant, elles ne doivent donc transporter que des requêtes idempotentes, jamais quoi que ce soit qui modifie un état. Une bonne réponse mentionne ce compromis sans qu'on le lui demande.