Qu'est-ce que TLS 1.3 ? Tout ce qui a changé

TLS 1.3 est la version actuelle du protocole Transport Layer Security, publiée sous la référence RFC 8446 en août 2018. C’est une refonte fondamentale — pas une mise à jour incrémentale — qui rend HTTPS plus rapide, plus simple et plus sécurisé que toute version précédente.

En 2026, 62 % des sites web supportent TLS 1.3, et tous les navigateurs majeurs le supportent depuis 2018.

Ce qui a changé par rapport à TLS 1.2

La philosophie de conception : supprimer tout ce qui peut être mal configuré. TLS 1.2 a 37 suites de chiffrement — certaines sécurisées, certaines cassées. TLS 1.3 en a 5, toutes sûres.

Les 5 suites de chiffrement TLS 1.3

TLS_AES_256_GCM_SHA384        ← La plus forte, la plus courante
TLS_AES_128_GCM_SHA256        ← Largement utilisée, légèrement plus rapide
TLS_CHACHA20_POLY1305_SHA256  ← Idéale pour ARM/mobile (pas d'AES-NI)
TLS_AES_128_CCM_SHA256        ← IoT/embarqué
TLS_AES_128_CCM_8_SHA256      ← IoT/embarqué (tag court)

Vous ne pouvez pas mal les configurer — ce sont toutes des chiffrements AEAD avec des clés fortes. Il n’y a aucun risque d’« activer accidentellement un chiffrement faible » comme dans TLS 1.2.

Handshake 1-RTT : pourquoi c’est plus rapide

Handshake TLS 1.2 (2 allers-retours) :

Client → Server:  ClientHello (chiffrements supportés)
Server → Client:  ServerHello, Certificate, KeyExchange
Client → Server:  KeyExchange, ChangeCipherSpec, Finished
Server → Client:  ChangeCipherSpec, Finished
                  [4 messages avant que les données chiffrées circulent]

Handshake TLS 1.3 (1 aller-retour) :

Client → Server:  ClientHello + KeyShare
Server → Client:  ServerHello + KeyShare + Certificate + Finished
Client → Server:  Finished
                  [les données chiffrées peuvent circuler après 1 aller-retour]

Le client envoie ses paramètres de partage de clé dès le premier message — pas besoin d’attendre que le serveur spécifie les algorithmes. Cela réduit le handshake de 2 allers-retours à 1.

Reprise 0-RTT

Pour les visiteurs de retour (qui se sont déjà connectés), TLS 1.3 supporte le 0-RTT — des données d’application chiffrées envoyées avec le tout premier message :

Client → Server:  ClientHello + KeyShare + EarlyData (requête chiffrée)
Server → Client:  ServerHello + réponse

La requête est envoyée avant que le handshake ne soit terminé. Compromis : les données 0-RTT sont vulnérables aux attaques par rejeu, donc elles ne doivent être utilisées que pour des requêtes idempotentes (GET, pas POST).

Forward Secrecy obligatoire

Dans TLS 1.2, vous pouviez utiliser l’échange de clés RSA — la clé RSA à long terme du serveur déchiffre directement le pré-secret maître. Si quelqu’un enregistre le trafic et vole plus tard la clé privée du serveur, il peut déchiffrer toutes les conversations passées.

TLS 1.3 supprime entièrement l’échange de clés RSA. Tout échange de clés utilise le Diffie-Hellman éphémère (ECDHE) — une paire de clés unique est générée pour chaque connexion. Voler la clé privée du serveur n’aide pas à déchiffrer les sessions passées. En savoir plus sur le Forward Secrecy →

Certificat chiffré

Dans TLS 1.2, le certificat du serveur (y compris le nom de domaine) est envoyé en clair pendant le handshake. Un observateur passif peut voir à quel site vous vous connectez.

Dans TLS 1.3, le certificat est envoyé après la dérivation des clés du handshake — il est chiffré. Le SNI (Server Name Indication) est encore visible dans TLS 1.3, mais Encrypted Client Hello (ECH) le chiffrera aussi à l’avenir.

Comment activer TLS 1.3

Vérifier s’il est déjà activé

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_3 2>/dev/null | grep "Protocol"
# Attendu : TLSv1.3

Nginx (1.13+ avec OpenSSL 1.1.1+)

ssl_protocols TLSv1.2 TLSv1.3;

TLS 1.3 est activé par défaut dans les versions modernes de Nginx — il suffit de ne pas le désactiver.

Apache (2.4.37+ avec OpenSSL 1.1.1+)

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

Cela active TLS 1.2 et 1.3.

Vérifier votre version d’OpenSSL

openssl version
# Requis : OpenSSL 1.1.1+ pour le support TLS 1.3

Si votre OpenSSL est plus ancien, mettez-le à jour ou mettez à jour votre système d’exploitation.

Dois-je forcer TLS 1.3 uniquement ?

Pas encore. Environ 38 % des sites ne supportent pas TLS 1.3, et certains clients (proxys d’entreprise, Java 8, anciens systèmes embarqués) ne supportent que TLS 1.2. Abandonner TLS 1.2 aujourd’hui exclurait certains utilisateurs.

Configuration recommandée : Supportez à la fois TLS 1.2 et 1.3. Cela vous donne la vitesse de TLS 1.3 pour les clients modernes tout en maintenant la compatibilité. C’est ce que font Google, Cloudflare et la plupart des grands sites.

Questions fréquemment posées

Ai-je besoin d’un nouveau certificat pour TLS 1.3 ?

Non. Le même certificat fonctionne avec TLS 1.2 et 1.3. Les certificats sont indépendants du protocole — ils contiennent une clé publique et une signature de CA, quelle que soit la version TLS qui les utilise.

TLS 1.3 affecte-t-il les performances ?

Oui, positivement. Le handshake 1-RTT économise 50-100ms lors de la première connexion. La reprise 0-RTT élimine complètement la latence du handshake pour les visiteurs de retour. Combiné avec HTTP/2 (qui nécessite HTTPS), les sites TLS 1.3 sont mesurablements plus rapides.

TLS 1.2 est-il encore sûr ?

Oui, avec des suites de chiffrement AEAD (AES-GCM, ChaCha20-Poly1305) et l’échange de clés ECDHE. Évitez les chiffrements CBC dans TLS 1.2 — ils ont été vulnérables à des attaques (BEAST, Lucky13). TLS 1.3 est meilleur, mais TLS 1.2 avec des chiffrements modernes reste sécurisé.

Et TLS 1.4 ?

Il n’y a pas de TLS 1.4 prévu. L’IETF considère TLS 1.3 comme la cible pour l’avenir prévisible. Le prochain changement majeur sera l’intégration de l’échange de clés post-quantique (ML-KEM) en hybride avec l’ECDHE existant — cela se fera au sein de TLS 1.3, pas en tant que nouvelle version.