TLS 1.2 vs TLS 1.3 : ce qu'on regarde en audit et ce qu'on configure
TLS est le protocole qui chiffre les connexions entre un navigateur et votre serveur. La version 1.2 est robuste et largement déployée. La version 1.3 est plus rapide et plus sûre par construction. Mais activer TLS 1.3 en mode "1.3 uniquement" sans vérifier la compatibilité de vos clients peut couper l'accès à une partie de votre audience. Voici ce qu'on vérifie dans nos audits et ce qu'on pousse en durcissement.
Définition en une phrase
TLS (Transport Layer Security) est le protocole cryptographique qui sécurise les connexions HTTPS entre un navigateur et un serveur. TLS 1.2 et TLS 1.3 sont les deux versions actuellement acceptables, les versions 1.0 et 1.1 étant considérées comme insuffisantes depuis 2020.
En clair, pour les non-initiés. Le "S" dans HTTPS vient de TLS. C'est ce protocole qui chiffre les données échangées entre vous et votre banque, entre vos clients et votre boutique en ligne. SSL est l'ancien nom de TLS (Secure Sockets Layer). Tout le monde dit encore "certificat SSL" mais le protocole actuel s'appelle TLS. SSL en tant que protocole est mort depuis des années.
Pourquoi c'est important pour votre site
TLS 1.0 et TLS 1.1 présentent des failles cryptographiques documentées (POODLE, BEAST, CRIME sur les suites de chiffrement disponibles). PCI-DSS a rendu leur désactivation obligatoire pour les sites e-commerce depuis 2018. La grande majorité des hébergeurs les ont désactivés, mais pas tous, surtout sur des configurations anciennes.
TLS 1.2 reste solide quand il est configuré avec les bonnes suites de chiffrement. Les suites vulnérables (RC4, 3DES, export ciphers) peuvent théoriquement être activées en 1.2 si la configuration est laxiste. On vérifie systématiquement les suites disponibles, pas seulement la version.
TLS 1.3 supprime toutes les suites de chiffrement vulnérables par construction. Il n'est pas possible de configurer TLS 1.3 de façon faible. Autre avantage : la poignée de main (handshake) est plus courte (1-RTT contre 2-RTT en 1.2), ce qui accélère légèrement l'établissement des connexions HTTPS.
Sur nos audits P.01, TLS 1.0 ou 1.1 encore actifs représentent environ 15 % des sites que nous inspectons, essentiellement sur des hébergements mutualisés anciens ou des serveurs dont la configuration Apache/Nginx n'a pas été revue depuis 2016.
Différence entre SSL et TLS
La confusion est fréquente. Voici les versions chronologiques :
| Version | Statut |
|---|---|
| SSL 1.0 | Jamais publié (trop de bugs) |
| SSL 2.0 | Désactivé partout depuis ~2011 |
| SSL 3.0 | Désactivé partout depuis ~2015 (POODLE) |
| TLS 1.0 | À désactiver, fin de vie officielle RFC 2020 |
| TLS 1.1 | À désactiver, fin de vie officielle RFC 2020 |
| TLS 1.2 | Valide si suites de chiffrement correctes |
| TLS 1.3 | Recommandé, plus rapide, plus sûr |
Quand votre hébergeur ou Cloudflare dit "certificat SSL", il parle en fait d'un certificat TLS. Le terme "SSL" est resté dans le vocabulaire courant par habitude.
Ce qu'on regarde en audit P.01
Dans chaque audit préventif, nous vérifions :
# Vérification des versions TLS supportées (via testssl.sh ou nmap)
testssl.sh --protocols votre-domaine.fr
# Exemple de sortie attendue (bon résultat) :
SSLv2 not offered
SSLv3 not offered
TLS 1 not offered
TLS 1.1 not offered
TLS 1.2 offered
TLS 1.3 offered
Et les suites de chiffrement disponibles en TLS 1.2 :
testssl.sh --cipher-per-proto votre-domaine.fr
On signale en sévérité haute : TLS 1.0 ou 1.1 encore actifs, suites RC4 ou 3DES disponibles, certificat expiré ou auto-signé.
On signale en sévérité moyenne : absence de TLS 1.3, suites DHE faibles (clés sous 2048 bits), HSTS absent (voir HSTS).
Ce qu'on configure en durcissement P.03
La configuration cible que nous poussons en P.03 :
Sur Nginx :
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m;
ssl_session_tickets off;
Sur Apache :
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite TLSv1.3 TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off
Via Cloudflare :
Dans SSL/TLS > Edge Certificates > Minimum TLS Version : on positionne à TLS 1.2. Cloudflare active TLS 1.3 automatiquement en complément. C'est la configuration qu'on applique dans PK.CFE.
Pourquoi on n'active pas TLS 1.3 uniquement
TLS 1.3 n'est pas supporté par tous les clients encore actifs. Les systèmes concernés :
- Android 6 et 7 (API 23-25) : support TLS 1.3 ajouté en Android 10 (API 29).
- IE 11 sur Windows 7 : ne supporte pas TLS 1.3.
- Certains systèmes embarqués, caisses enregistreuses, terminaux de paiement avec des piles TLS anciennes.
Pour un site grand public avec une audience mobile large, désactiver TLS 1.2 en ne gardant que 1.3 peut bloquer une fraction non négligeable des utilisateurs sur des appareils anciens. Pour un SaaS B2B dont tous les clients sont sur Chrome récent, l'impact est quasi nul.
Notre recommandation standard : TLS 1.2 + TLS 1.3 ensemble. On désactive 1.0 et 1.1, on active 1.3 en complément sans supprimer 1.2. C'est le bon équilibre sécurité/compatibilité pour la grande majorité des sites.
Les erreurs qu'on rencontre le plus souvent
1. TLS 1.0 ou 1.1 encore actifs sur un hébergement mutualisé
L'hébergeur a une configuration Apache partagée entre tous les clients. Si la configuration globale n'a pas été mise à jour, tous les sites hébergés sont exposés. On ne peut pas toujours corriger ça sans accès au fichier de configuration du serveur ou sans passer par le support hébergeur.
2. Certificat Let's Encrypt expiré
Let's Encrypt délivre des certificats valides 90 jours avec renouvellement automatique via Certbot ou acme.sh. Quand le renouvellement automatique échoue (permission, cron manquant, port 80 bloqué), le certificat expire et les navigateurs affichent un avertissement de sécurité. Ce n'est pas un problème de version TLS, mais on le détecte dans la même vérification. On l'observe sur environ 8 % des sites que nous auditons.
3. HSTS sans TLS correctement configuré
Activer HSTS avant d'avoir vérifié que TLS est correctement configuré crée une dépendance : le navigateur force HTTPS, mais si le certificat est faible ou expiré, l'accès au site est bloqué sans possibilité de repli. TLS d'abord, HSTS ensuite.
4. Suites de chiffrement 3DES ou RC4 encore disponibles en TLS 1.2
Une configuration TLS 1.2 laxiste peut exposer des suites 3DES (vulnérable à SWEET32) ou RC4 (compromis cryptographiquement). La version du protocole est nécessaire mais pas suffisante : on vérifie les suites disponibles.
Questions fréquentes
SSL et TLS sont-ils la même chose ? Non, mais en pratique on confond les deux. SSL est le nom de l'ancienne version du protocole (SSL 2.0, SSL 3.0), toutes désactivées aujourd'hui. TLS (1.2, 1.3) est le protocole actuel. Un "certificat SSL" est en réalité un certificat X.509 utilisé avec TLS. Le terme "SSL" reste dans le langage courant par habitude.
TLS 1.3 est-il vraiment plus rapide ? Oui, de façon mesurable sur des connexions à haute latence. La poignée de main TLS 1.3 prend 1 aller-retour (1-RTT) contre 2 en TLS 1.2. Sur un réseau mobile avec 50 ms de latence, ça représente 50 ms gagnées par connexion HTTPS. L'impact est visible sur les temps de chargement de première page.
Mon site est sur Cloudflare. Dois-je quand même vérifier TLS côté serveur ? Oui, pour deux raisons. D'abord, le Cloudflare en mode Flexible parle à votre serveur en HTTP, donc TLS ne s'applique qu'entre le visiteur et Cloudflare, pas entre Cloudflare et votre serveur. En mode Full (Strict), le chiffrement s'applique sur toute la chaîne : la configuration TLS de votre serveur compte. On vérifie les deux dans nos audits.
Cloudflare Pro est-il nécessaire pour TLS 1.3 ? Non. TLS 1.3 est disponible sur tous les plans Cloudflare, y compris Free. La configuration Minimum TLS Version se trouve dans SSL/TLS > Edge Certificates.
Qu'est-ce qu'un cipher suite et pourquoi est-ce important ? Une suite de chiffrement (cipher suite) est la combinaison d'algorithmes utilisée pour la poignée de main TLS et le chiffrement des données : échange de clés (ECDHE), algorithme de chiffrement (AES-128-GCM), et hachage (SHA-256). Une suite faible en TLS 1.2 peut rendre le protocole vulnérable même si la version est récente. En TLS 1.3, les suites faibles sont supprimées par construction.
Pour aller plus loin
- Connexe : HSTS, Cloudflare WAF, SSH hardening.
- Protocoles concernés : TLS est audité dans l'audit préventif P.01 (490 € TTC, 48 h). La configuration TLS est corrigée dans le durcissement sécurité P.03 (790 € TTC, 72 h) et dans le pack Sérénité Cloudflare PK.CFE.
TLS 1.0 encore actif ou suites de chiffrement faibles détectées sur votre site ? Notre audit préventif (P.01, 490 € TTC, livré en 48 h) vérifie les versions TLS, les suites de chiffrement et les headers HTTP. Rapport PDF priorisé, sans accès serveur. Briefer un audit préventif