Poignée de main TLS

Le poignée de main TLS est l'échange de protocole qui établit une connexion cryptée et authentifiée entre deux points de terminaison. Il s'exécute au début de chaque requête HTTPS, chaque session SMTP sécurisée, chaque connexion IMAP moderne, chaque connexion HTTP/2 et HTTP/3. La version actuelle, TLS 1.3 (RFC 8446, 2018), est considérablement plus simple et plus rapide que TLS 1.2.

Ce que la poignée de main réalise

À la fin de la poignée de main, les deux parties ont :

• Vérifié l'identité du serveur via un certificat
• Convenu sur une version TLS et suite de chiffrement
• Clés symétriques partagées dérivées pour la session
• Authentification échangée en option pour le client (mTLS)
• Détails de la couche application signalés en option (ALPN : quelle version de HTTP, etc.)

Toutes les données ultérieures utilisent les clés symétriques (généralement AES-GCM ou ChaCha20-Poly1305) pour un cryptage en masse rapide. Prise de contact

TLS 1.3, étape par étape

La prise de contact minimale dans TLS 1.3 est de 1 aller-retour :

1. ClientBonjour. Le client envoie :
   • Supporté Versions TLS
   • Suites de chiffrement qu'il peut parler
   • Groupes d'échange de clés pris en charge (X25519, secp256r1, etc.)
   • Partage de clés — sa clé publique éphémère pour l'échange de clés. Il s'agit de l'accélération TLS 1.3 : dans TLS 1.2, l'échange de clés attendait les paramètres du serveur ; TLS 1.3 devine et envoie immédiatement la clé publique.
   • SNI (Indication du nom du serveur) — avec quel nom d'hôte le client souhaite parler. Historiquement le texte en clair ; Le client crypté Hello (ECH) est déployé pour le masquer. chiffré
   • Sa chaîne de certificat (cryptée sous les clés de prise de contact)
   • Une signature prouvant qu'il détient la clé privée correspondant au certificat
   • Message terminé confirmant que les deux parties ont la même transcription de prise de contact
2. Le client envoie Terminé. Accepte les messages du serveur et passe à l'utilisation des clés d'application dérivées.
3. Données d'application. La première requête HTTP circule.

Coût net : 1 aller-retour avant le premier octet d'application. Avec 0-RTT (une fonctionnalité TLS 1.3 qui utilise les clés de session mises en cache d'une connexion précédente), la première requête peut circuler dans le ClientHello lui-même — aucun aller-retour pour les sessions reprises.

TLS 1.2 était plus lent. partage de clé pour le moment)

ServerHello + Certificate + ServerKeyExchange + ServerHelloDone

ClientKeyExchange + ChangeCipherSpec + Finished

ChangeCipherSpec + Finished

Application data

Le coût des 2 allers-retours importait le plus réseaux à haute latence. La prise de contact 1-RTT (ou 0-RTT) de TLS 1.3 a été l'une des améliorations les plus importantes des performances Web perceptibles par l'utilisateur au cours de la dernière décennie. SSL 3.0, TLS 1.0, 1.1 sont obsolètes.

Cipher suite. Spécifie le chiffrement symétrique (AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305), la fonction de hachage (SHA-256, SHA-384) et (dans TLS 1.2), le mécanisme d'échange de clés. TLS 1.3 sépare ces groupes d'échange de clés

. X25519, secp256r1, secp384r1, etc. ECC est la valeur par défaut ; L'échange de clés RSA est supprimé dans l'algorithme 1.3.

Signature. RSA-PSS, ECDSA, Ed25519. La signature de certificat du serveur utilise l'un d'entre eux. - chaque session dérive des clés à partir de nouvelles clés éphémères supprimées immédiatement après. Si la clé privée à long terme du serveur fuit demain, le trafic capturé aujourd'hui est toujours protégé (en supposant que la fuite n'inclut pas les clés éphémères, qui ne sont généralement jamais conservées).

TLS 1.2 a rendu cela facultatif via les chiffrements DHE/ECDHE ; de nombreux serveurs l'ont activé, mais certains ne l'ont pas fait. TLS 1.3 le rend non négociable.

Validation du certificat

Le serveur prouve son identité en envoyant une chaîne de certificats. Le client vérifie :

• Le nom du certificat feuille correspond à l'hôte auquel est connecté
• Le certificat est à date
• Chaque certificat de la chaîne est signé par le suivant
• La racine se trouve dans le magasin de confiance local
• Les journaux de transparence du certificat incluent le certificat (navigateurs modernes)
• Le certificat n'est pas révoqué (CRL, OCSP ou équivalents modernes comme CRLite)

Si une vérification échoue, le navigateur affiche un avertissement. Consultez notre article CA pour une vue d'ensemble.

0-RTT et risque de relectureLe mode 0-RTT de

TLS 1.3 permet à un client qui revient d'envoyer des données d'application dans son premier paquet, en utilisant des clés dérivées d'une session précédente. Le compromis : un attaquant qui capture les données 0-RTT peut les rejouer plus tard. Pour les opérations idempotentes (requêtes GET pour le contenu pouvant être mis en cache), cela convient. Pour les opérations non idempotentes (POST de changement d'état), 0-RTT n'est pas sûr. La plupart des navigateurs et des CDN gèrent cela avec précaution ; les serveurs peuvent refuser 0-RTT pour des opérations spécifiques.