Handshake TLS.

Le handshake TLS négocie la version du protocole, la cipher suite, l'identité du serveur et les clés de session avant tout envoi de données applicatives. En TLS 1.2 (RFC 5246), le handshake prend deux aller-retours et utilise ClientHello, ServerHello, Certificate, ServerKeyExchange, ainsi qu'une paire de Finished qui confirme la transcription négociée. TLS 1.3 (RFC 8446, 2018) le ramène à un seul aller-retour, chiffre tout ce qui suit le ServerHello, supprime les primitives héritées (RC4, modes CBC sans AEAD, échange de clés RSA statique, compression) et prend en charge la reprise 0-RTT — rapide mais vulnérable au rejeu, donc à réserver aux requêtes idempotentes.

Les deux versions modernes imposent (EC)DHE éphémère pour la forward secrecy et authentifient le serveur via un certificat X.509 validé le long d'une chaîne de confiance. Le hachage de la transcription du handshake et le MAC du Finished sont précisément ce qui a historiquement déjoué les attaques de downgrade et de renégociation : POODLE (2014) forçait les victimes à redescendre vers le padding CBC de SSL 3.0, FREAK et Logjam (2015) imposaient du RSA/DH de qualité export, et BEAST exploitait les IV CBC de TLS 1.0. La sentinelle de protection contre le downgrade dans le random serveur de TLS 1.3 signale désormais toute altération. D'autres modes de défaillance importants en exploitation incluent les cipher suites faibles ou obsolètes, les certificats expirés ou mal émis, l'absence d'OCSP stapling et les incohérences entre SNI et certificat sur une infrastructure mutualisée.

sequenceDiagram
  participant C as Client
  participant S as Serveur
  C->>S: ClientHello (versions, cipher suites, partage de clé)
  S->>C: ServerHello (suite choisie, partage de clé)
  S->>C: Certificate + CertificateVerify
  S->>C: Finished
  Note over C,S: Les deux dérivent les clés symétriques via (EC)DHE
  C->>S: Finished
  C->>S: Données applicatives chiffrées