TLS 1.2 vs TLS 1.3 Handshake
Comparaison de l'efficacité du handshake et des améliorations de sécurité
Laurent Goudet · 20 janvier 2026 · 4 min de lecture
TLS 1.2
⏳ Le client a attendu pour savoir quel échange de clés utiliser
TLS 1.3
🔑 Clé ECDH du client envoyée d’emblée (X25519/P-256)
🔒 Chiffré à partir d’ici
| Caractéristique | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Allers-retours (handshake complet) | 2-RTT | 1-RTT |
| Échange de clé client | Attend le choix du serveur | Envoyé d'emblée via key_share |
| Reprise de session | 1-RTT | 0-RTT (avec réserves) |
| Chiffrement du handshake | ✗ En clair | ✓ Après ServerHello |
| Confidentialité persistante | Optionnelle (ECDHE) | ✓ Obligatoire |
| Échange de clé RSA | ✗ Autorisé (pas de PFS) | ✓ Retiré |
| Suites de chiffrement | ~40 options | 5 options sécurisées |
| Algorithmes obsolètes | MD5, SHA-1, RC4, DES… | Tous retirés |
🔒
TLS 1.2 : Le client doit attendre de connaître l’algorithme d’échange de clés (RSA, DHE, ECDHE) et la courbe choisis par le serveur avant de pouvoir envoyer sa clé. Cela impose un second aller-retour.
TLS 1.3 : Le client envoie son key_share
d’emblée dans le premier message, généralement pour X25519 ou P-256. Comme
TLS 1.3 a retiré l’échange de clé RSA et réduit les suites de chiffrement
de ~40 à 5, ces suppositions fonctionnent presque toujours.
Et si le serveur ne supporte pas les courbes proposées ?
Le serveur envoie un HelloRetryRequest demandant un autre key
share, revenant à 2-RTT. Cela se produit dans moins de 1% des connexions
car X25519/P-256 sont quasi universels.
Déploiement en conditions réelles
Support navigateur. Tous les navigateurs modernes supportent TLS 1.3 depuis 2018-2019 (Chrome 70, Firefox 63, Safari 12.1, Edge 79). En 2026, TLS 1.3 représente la majorité des connexions HTTPS sur l’internet public. La transition s’est faite plus rapidement que pour toute version TLS précédente, car le gain de performance (un aller-retour en moins) incitait clients et serveurs à migrer.
La longue traîne de TLS 1.2. Malgré l’adoption massive de TLS 1.3, TLS 1.2 reste nécessaire dans plusieurs contextes. Les environnements conformes PCI DSS imposent souvent des suites de chiffrement spécifiques correspondant à des configurations TLS 1.2. Les environnements d’entreprise avec du matériel historique (répartiteurs de charge, HSM, passerelles IoT) peuvent ne pas supporter TLS 1.3. Le conseil pratique : configurez TLS 1.2 et 1.3, préférez 1.3, et surveillez quelle version les clients négocient réellement.
Planifier la dépréciation. TLS 1.0 et 1.1 sont déjà dépréciés (RFC 8996, mars 2021). La dépréciation de TLS 1.2 n’est pas imminente mais se profile. Surveillez vos logs de négociation — si moins de 1 % des clients ont besoin de TLS 1.2, vous pouvez exiger 1.3 en toute sécurité et réduire votre surface d’attaque. Cloudflare, AWS et GCP permettent tous de configurer la version TLS minimale par point de terminaison.
TLS 1.3 réduit la latence tout en améliorant la sécurité en supprimant les algorithmes obsolètes et en chiffrant davantage le handshake.
Questions fréquentes
Combien d'allers-retours TLS 1.3 nécessite-t-il par rapport à TLS 1.2 ?
TLS 1.3 nécessite 1 aller-retour (1-RTT) pour un handshake complet contre 2 allers-retours (2-RTT) pour TLS 1.2. TLS 1.3 supporte également la reprise de session 0-RTT.
Pourquoi TLS 1.3 est-il plus rapide que TLS 1.2 ?
TLS 1.3 envoie la clé du client d'emblée dans le ClientHello, ce qui élimine l'aller-retour supplémentaire que TLS 1.2 nécessite pour négocier l'algorithme d'échange de clés.
TLS 1.3 est-il plus sécurisé que TLS 1.2 ?
Oui. TLS 1.3 supprime tous les algorithmes obsolètes (MD5, SHA-1, RC4, DES), impose la confidentialité persistante, retire l'échange de clé RSA et chiffre davantage le handshake.
Qu'est-ce que le 0-RTT dans TLS 1.3 et quels sont les risques ?
Le 0-RTT permet aux clients d'envoyer des données applicatives chiffrées dès le premier message lors de la reprise d'une session précédente, grâce à des clés pré-partagées. Le risque est l'attaque par rejeu : les données 0-RTT ne sont pas protégées par la valeur aléatoire du serveur, un attaquant peut donc les capturer et les renvoyer. Les serveurs ne doivent accepter le 0-RTT que pour les requêtes idempotentes (GET, pas POST) et utiliser des tickets de session à usage unique pour limiter la fenêtre de rejeu.
Autres analyses
TLS vs mTLS Handshake
Comparaison des flux d'authentification TLS standard et mutuel
Ingénierie réseauRéseau IPv6-Only avec NAT64/464XLAT
Faire fonctionner un réseau local IPv6-only tout en maintenant la connectivité IPv4
Ingénierie CDNLe piège == false en Fastly VCL
Comment l'utilisation de == false au lieu de ! dans des conditions composées en Fastly VCL peut silencieusement casser votre logique
IA & IndustrieQuelque chose de grand se passe — mais pas ce que vous croyez
Pourquoi l'IA est un changement de couche d'abstraction, pas la fin du travail intellectuel — la réponse d'un praticien à l'essai viral sur l'IA
IA & IndustrieOrchestration d'agents IA à grande échelle — Ce qui fonctionne vraiment en production
Patterns et leçons tirées de l'exploitation de systèmes multi-agents à l'échelle de 80M+ utilisateurs : routage, chaînes de fallback, gestion du contexte, et pourquoi la plupart des architectures d'agents échouent.
Sécurité réseauDNSSEC : chaîne de confiance de la racine à ce domaine
Comment DNSSEC construit une chaîne de confiance cryptographique de la racine DNS à cette zone — avec configuration Pulumi et vérification dig en direct
Sécurité réseauDéployer DMARC à grande échelle
Guide pratique pour déployer DMARC sur une grande plateforme — corrections SPF, DKIM et alignement à travers AWS SES, Google Workspace, des relais Postfix et des dizaines de domaines
Cloud SecurityVotre cle API Google Maps peut maintenant vider votre compte en banque
Google a silencieusement modifie les permissions des cles API pour que celles destinees a Maps puissent desormais appeler Gemini AI. Voici comment auditer vos projets GCP et verrouiller les cles exposees.