TLS 1.2 vs TLS 1.3 : changements et configuration

TLS 1.2 vs TLS 1.3 n’est plus un choix entre deux égaux. TLS 1.2 (RFC 5246, 2008) est sûr lorsqu’on le restreint à l’échange de clés ECDHE et aux suites de chiffrement AEAD ; TLS 1.3 (RFC 8446 en 2018, révisée par la RFC 9846 en juillet 2026) en fait la seule option, chiffre une plus grande partie du handshake et est la seule version à offrir l’échange de clés hybride post-quantique et Encrypted Client Hello.

Vue d’ensemble

Le handshake

TLS 1.2 négocie d’abord et échange les clés ensuite : le client liste des suites de chiffrement, le serveur en choisit une et envoie son certificat et ses paramètres d’échange de clés, le client envoie sa key share, et les deux concluent. Deux allers-retours s’écoulent avant que les données applicatives ne circulent, et le certificat transite en clair. Avec les suites à RSA statique, le client chiffre le secret pré-maître (premaster secret) avec la clé du certificat du serveur : quiconque obtient plus tard cette clé peut donc déchiffrer toutes les sessions enregistrées.

TLS 1.3 anticipe : le client envoie dès le premier message des key shares pour ses groupes préférés, le serveur répond avec la sienne, suivie immédiatement des extensions chiffrées, du certificat, de CertificateVerify et de Finished, et le client peut envoyer des données après un seul aller-retour. Les sessions reprises peuvent même transporter des données précoces 0-RTT, au prix de la protection contre le rejeu pour ces données.

Le script ci-dessous, exécuté avec OpenSSL 3.6.5 contre un serveur public le 20 octobre 2026, montre le résultat concret lorsque le même client impose chaque version.

#!/bin/sh
host=${1:-cloudflare.com}
for version in -tls1_2 -tls1_3; do
  echo "== $version"
  echo | openssl s_client -connect "$host:443" -servername "$host" "$version" -brief 2>&1 \
    | grep -E "Protocol version|Ciphersuite|Peer Temp Key|Negotiated TLS1.3 group"
done

== -tls1_2
Protocol version: TLSv1.2
Ciphersuite: ECDHE-ECDSA-CHACHA20-POLY1305
Peer Temp Key: X25519, 253 bits
== -tls1_3
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Negotiated TLS1.3 group: X25519MLKEM768

La connexion TLS 1.2 est sûre ici, car le serveur n’autorise qu’ECDHE avec AEAD, mais elle se limite au X25519 classique ; la connexion TLS 1.3 négocie l’hybride post-quantique.

Ce que TLS 1.3 a supprimé, et pourquoi

Presque toutes les attaques célèbres contre TLS des années 2010 exploitaient une fonctionnalité de l’époque de TLS 1.2 que TLS 1.3 a supprimée :

• Mode CBC avec MAC puis chiffrement (BEAST, Lucky Thirteen, POODLE) : seuls les algorithmes de chiffrement AEAD subsistent.
• RC4 (biais statistiques) et 3DES (SWEET32) : supprimés.
• Transport de clé RSA (oracles de remplissage de Bleichenbacher, ROBOT ; pas de confidentialité persistante) : supprimé.
• Groupes de niveau export et groupes arbitraires sur corps finis (FREAK, Logjam) : seuls les groupes nommés subsistent.
• Renégociation et compression (triple handshake, CRIME) : supprimées.
• Signatures sur des transcriptions partielles (le ServerKeyExchange de TLS 1.2 ne signe que des paramètres) : CertificateVerify signe toute la transcription.
• SHA-1 et MD5 dans les signatures : supprimés.

La RFC 9846 renforce aussi les exigences envers les implémentations de TLS 1.2, et la RFC 9325 définit le sous-ensemble sûr de TLS 1.2 : ECDHE ou DHE avec AEAD, secret maître étendu (RFC 7627) et renégociation sécurisée.

Fonctionnalités propres à TLS 1.3

• Échange de clés hybride post-quantique (X25519MLKEM768, RFC 10024), négocié par défaut dans les principaux navigateurs depuis fin 2024 et dans OpenSSL depuis la 3.5.
• Encrypted Client Hello (RFC 9849), qui masque le nom du serveur aux yeux du réseau lorsqu’il est utilisé avec des enregistrements DNS HTTPS.
• Compression des certificats (RFC 8879) et identifiants délégués (delegated credentials, RFC 9345).
• QUIC, qui intègre le handshake TLS 1.3 et sert de transport à HTTP/3.

Conformité et politiques

• Systèmes fédéraux américains : NIST SP 800-52 Rev. 2 impose aux serveurs TLS gouvernementaux de prendre en charge TLS 1.3 au plus tard le 1er janvier 2024 et autorise TLS 1.2 avec des suites approuvées.
• Environnements de cartes de paiement : PCI DSS interdit SSL et les premières versions de TLS (1.0) depuis le 30 juin 2018 ; TLS 1.2 et 1.3 sont tous deux acceptables.
• IETF : la RFC 8996 a déclaré TLS 1.0 et 1.1 obsolètes en 2021 ; les navigateurs les avaient retirés en 2020.
• Plans post-quantiques : NIST IR 8547 (projet) et CNSA 2.0 supposent un établissement de clés hybride ou post-quantique, qui n’est disponible que dans TLS 1.3.

Quand choisir l’un ou l’autre

• Sites web et API publics : TLS 1.3 de préférence, TLS 1.2 limité au sous-ensemble sûr en solution de repli.
• Services internes, maillages de services (service meshes), mTLS : TLS 1.3 uniquement.
• Clients anciens (vieux Android, appareils embarqués, anciennes versions de Java et de Windows) : TLS 1.2 avec ECDHE et AEAD ; planifiez leur retrait.
• Équipements intermédiaires (middleboxes) qui inspectent le trafic : attendez-vous à devoir les mettre à jour pour TLS 1.3, ECH et les gros ClientHello post-quantiques, plutôt que de brider les serveurs.
• Tout ce qui exige une confidentialité post-quantique : TLS 1.3 avec un groupe hybride.

Notes de migration

1. Mettez à jour la bibliothèque TLS : OpenSSL 1.1.1 ou ultérieur pour TLS 1.3, 3.5 ou ultérieur pour les groupes post-quantiques par défaut ; BoringSSL et Go à jour, Java 11 ou ultérieur, Windows Server 2022 ou ultérieur.
2. Activez TLS 1.3 à côté de la 1.2, puis restreignez la 1.2 aux suites ECDHE et AEAD ; dans nginx, ssl_protocols TLSv1.2 TLSv1.3; avec une courte liste ssl_ciphers, puisque les suites TLS 1.3 se configurent séparément.
3. Vérifiez les certificats et les clés : les certificats RSA fonctionnent avec TLS 1.3, car les signatures du handshake utilisent PSS avec les mêmes clés ; les certificats ECDSA fonctionnent sans changement.
4. Statuez sur le 0-RTT : laissez-le désactivé, sauf si l’application peut gérer sans risque le rejeu des requêtes précoces.
5. Mesurez le trafic TLS 1.2 restant et fixez une date pour le désactiver là où il tombe à zéro. Le générateur de configurations TLS produit des réglages pour les serveurs courants, et le vérificateur de domaines en masse indique quelles versions vos hôtes acceptent.

Références

• RFC 9846, TLS 1.3 (§1.3 différences avec TLS 1.2, §1.4 mises à jour qui concernent TLS 1.2)
• RFC 5246, TLS 1.2
• RFC 9325, recommandations pour un usage sûr de TLS et DTLS
• RFC 8996, abandon de TLS 1.0 et TLS 1.1
• RFC 10024, accord de clé ML-KEM hybride pour TLS 1.3
• RFC 9849, Encrypted Client Hello pour TLS
• NIST SP 800-52 Rev. 2
• PCI SSC : migrer depuis SSL et les premières versions de TLS