SSL (Secure Sockets Layer) et TLS (Transport Layer Security) sont tous deux des protocoles cryptographiques qui chiffrent les connexions internet. La différence pratique : toutes les versions de SSL sont obsolètes et non sécurisées. TLS est ce qui sécurise réellement le web aujourd’hui. Quand les gens disent “certificat SSL”, ils désignent un certificat utilisé avec TLS.
Si vous êtes ici pour savoir si vous devez faire quelque chose — passez directement à ce que vous devez faire.
Comparaison rapide
| SSL | TLS | |
|---|---|---|
| Nom complet | Secure Sockets Layer | Transport Layer Security |
| Créé par | Netscape (1994) | IETF (1999) |
| Dernière version | SSL 3.0 (1996) | TLS 1.3 (2018) |
| Statut | Toutes les versions obsolètes | TLS 1.2 et 1.3 en usage actif |
| Vulnérabilités connues | POODLE, BEAST, CRIME, DROWN | Aucune (TLS 1.3), quelques-unes atténuables (TLS 1.2) |
| Performance | Plus lent (2+ allers-retours) | TLS 1.3 : handshake en 1-RTT |
| Forward Secrecy | Optionnel (rarement utilisé) | Obligatoire dans TLS 1.3 |
| Suites de chiffrement | Faibles (RC4, DES, chiffrements d’export) | Fortes (AES-GCM, ChaCha20) |
| Authentification des messages | MAC avec MD5/SHA-1 | HMAC avec SHA-256+ |
| Support navigateur | Retiré de tous les navigateurs | Universel |
L’historique complet des versions
| Année | Protocole | Ce qui s’est passé |
|---|---|---|
| 1994 | SSL 1.0 | Conçu par Netscape. Jamais publié — des failles graves découvertes en interne avant le lancement. |
| 1995 | SSL 2.0 | Première version publique. Utilisé par les premiers sites HTTPS. Rapidement reconnu comme ayant des vulnérabilités majeures (MAC faible, susceptible aux attaques de troncature). |
| 1996 | SSL 3.0 | Refonte complète par Paul Kocher + Netscape. Largement déployé pendant 18 ans. Cassé par l’attaque POODLE (octobre 2014). Déclaré obsolète par l’IETF en juin 2015 (RFC 7568). |
| 1999 | TLS 1.0 | Protocole standardisé par l’IETF basé sur SSL 3.0. Améliorations mineures. Vulnérable à l’attaque BEAST (2011). Déclaré obsolète en mars 2021 (RFC 8996). |
| 2006 | TLS 1.1 | Correction de la vulnérabilité BEAST. Ajout d’un IV explicite pour les chiffrements CBC. Obsolète depuis mars 2021 avec TLS 1.0. |
| 2008 | TLS 1.2 | Mise à jour majeure. Ajout des chiffrements AEAD (AES-GCM), suppression de MD5/SHA-1 du handshake, ajout de la négociation des algorithmes de signature. Toujours largement utilisé et sécurisé lorsqu’il est correctement configuré. |
| 2018 | TLS 1.3 | Standard actuel (RFC 8446). Suppression de tous les algorithmes hérités, handshake en 1-RTT, Forward Secrecy obligatoire, handshake chiffré. Représente une refonte fondamentale. |
Moments clés :
- Octobre 2014 : Google découvre la vulnérabilité POODLE — SSL 3.0 ne peut pas être corrigé, doit être abandonné
- Juin 2015 : L’IETF déclare officiellement SSL 3.0 obsolète (RFC 7568)
- Mars 2021 : L’IETF déclare TLS 1.0 et 1.1 obsolètes (RFC 8996)
- 2020-2021 : Tous les navigateurs majeurs abandonnent le support de TLS 1.0/1.1
Pourquoi on dit encore “SSL”
Le terme “SSL” est resté car il est arrivé en premier. Netscape l’a inventé en 1994, et quand TLS l’a remplacé en 1999, “SSL” était déjà un terme courant. Aujourd’hui :
- “Certificat SSL” = un certificat utilisé avec TLS (pas SSL)
- “SSL/TLS” = une formulation couvrant les deux termes
- “SSL” dans les noms de produits = marketing, pas le protocole réel
- “SSL gratuit” = un certificat TLS gratuit
GetHTTPS, Certbot, Let’s Encrypt, ZeroSSL — tous émettent des certificats pour des connexions TLS, même quand leurs noms ou leur marketing dit “SSL”. Les certificats eux-mêmes sont au format X.509 et fonctionnent avec toute version de TLS.
Cet article utilise “certificat SSL” comme le fait l’industrie : pour désigner un certificat utilisé avec TLS.
Différences techniques importantes
Suites de chiffrement
SSL reposait sur des algorithmes que l’on sait maintenant cassés :
| Algorithme | Utilisé dans | Statut |
|---|---|---|
| RC4 | SSL 2.0, 3.0 | Cassé — RFC 7465 l’interdit |
| DES, 3DES | SSL 2.0, 3.0 | Cassé/obsolète |
| MD5 | Handshake SSL | Attaques par collision démontrées |
| Chiffrements d’export | SSL (politique US) | Intentionnellement faibles (clés 40/56 bits) |
| AES-GCM | TLS 1.2, 1.3 | Standard actuel |
| ChaCha20-Poly1305 | TLS 1.2, 1.3 | Excellent pour mobile/ARM |
TLS 1.3 réduit la liste des suites de chiffrement à seulement 5 options — toutes sécurisées. TLS 1.2 en a 37+, dont certaines sont faibles. La simplicité de TLS 1.3 signifie moins de risques de mauvaise configuration.
Vitesse du handshake
| SSL 3.0 | TLS 1.2 | TLS 1.3 | |
|---|---|---|---|
| Handshake complet | 2+ allers-retours | 2 allers-retours | 1 aller-retour |
| Session reprise | 1 aller-retour | 1 aller-retour | 0-RTT (données dès le premier message) |
| Latence pratique | 60-120ms | 40-80ms | 20-40ms |
La reprise 0-RTT de TLS 1.3 signifie que les visiteurs de retour peuvent envoyer des données chiffrées immédiatement — sans aucun délai de handshake.
Forward Secrecy
Le Forward Secrecy signifie que chaque connexion utilise une clé unique. Même si quelqu’un vole la clé privée du serveur, il ne peut pas déchiffrer les conversations passées.
- SSL 3.0 : Ne supportait pas le Forward Secrecy
- TLS 1.0-1.2 : Le supporte (via ECDHE) mais autorise aussi l’échange de clés RSA (pas de Forward Secrecy)
- TLS 1.3 : Obligatoire — l’échange de clés RSA a été entièrement supprimé
Authentification des messages
- SSL : Utilisait MAC avec MD5 ou SHA-1 — tous deux considérés comme faibles aujourd’hui
- TLS : Utilise HMAC avec SHA-256 ou plus fort — aucune faiblesse connue
Ce que vous devez faire
Pour la plupart des opérateurs de sites web : probablement rien. Si vous :
- Avez un certificat SSL/TLS valide (de Let’s Encrypt ou toute autre CA)
- Utilisez un serveur web raisonnablement moderne (Nginx 1.13+, Apache 2.4.37+, IIS 10)
- N’avez pas explicitement désactivé TLS 1.2/1.3 dans votre configuration
…alors vous utilisez déjà TLS. Votre “certificat SSL” fonctionne avec TLS 1.2 et 1.3 automatiquement — les mêmes fichiers .pem servent les deux protocoles.
Une chose à vérifier : Assurez-vous que TLS 1.0 et 1.1 sont désactivés sur votre serveur. Ils sont obsolètes depuis 2021.
Nginx :
ssl_protocols TLSv1.2 TLSv1.3;Apache :
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1Comment vérifier votre version TLS actuelle :
# Affiche quelle version TLS est négociée
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | grep "Protocol"
# Attendu : TLSv1.2 ou TLSv1.3Outil en ligne : Le SSL Labs Server Test montre exactement quels protocoles votre serveur prend en charge.
Adoption de TLS 1.3
Début 2026, 62 % des sites web supportent TLS 1.3. Tous les navigateurs majeurs le supportent. Si votre serveur est à jour, vous avez probablement déjà TLS 1.3.
Serveurs qui supportent TLS 1.3 nativement (aucune configuration spéciale nécessaire) :
- Nginx 1.13+ (avec OpenSSL 1.1.1+)
- Apache 2.4.37+ (avec OpenSSL 1.1.1+)
- Caddy (toutes versions — utilise toujours le TLS le plus récent)
- Cloudflare (automatique)
- AWS ALB/CloudFront (automatique)
Ce qui vient ensuite : la cryptographie post-quantique
La prochaine évolution majeure de TLS est l’échange de clés post-quantique — une protection contre les futurs ordinateurs quantiques qui pourraient casser les algorithmes d’échange de clés actuels (ECDHE, RSA). Google Chrome et Cloudflare ont déjà commencé à expérimenter l’échange de clés hybride (classique + post-quantique) dans TLS 1.3.
Cela ne nécessitera pas de nouveaux certificats — le changement concerne le mécanisme d’échange de clés, pas le format du certificat. Votre certificat Let’s Encrypt fonctionnera avec le TLS post-quantique quand il arrivera.
Questions fréquemment posées
Ai-je besoin d’un certificat différent pour TLS par rapport à SSL ?
Non. Le même certificat fonctionne avec toute version de TLS. “Certificat SSL” et “certificat TLS” désignent le même fichier X.509. Quand vous obtenez un certificat de GetHTTPS, il fonctionne avec TLS 1.2 et 1.3 — aucune configuration spéciale.
TLS 1.2 est-il encore sécurisé ?
Oui. TLS 1.2 avec des suites de chiffrement AEAD (AES-GCM ou ChaCha20-Poly1305) est sécurisé pour la production. TLS 1.3 est meilleur (plus rapide, plus simple, impose le Forward Secrecy), mais TLS 1.2 reste sûr. La configuration recommandée est TLSv1.2 TLSv1.3.
Dois-je forcer TLS 1.3 uniquement ?
Pas encore. Environ 38 % des sites ne supportent pas TLS 1.3, et certains clients plus anciens (environnements d’entreprise, appareils embarqués, Java 8) ne supportent peut-être que TLS 1.2. Abandonner TLS 1.2 aujourd’hui exclurait certains utilisateurs légitimes. Supportez les deux.
Les “certificats SSL” vont-ils cesser de fonctionner ?
Non. Malgré le nom, les “certificats SSL” sont des certificats X.509 qui fonctionnent avec toute version de TLS. Le nom est un vestige historique. Vos certificats continueront de fonctionner tant que la CA est de confiance et que le certificat n’est pas expiré.
HTTPS est-il la même chose que SSL ou TLS ?
HTTPS est HTTP + TLS. C’est le résultat de l’application du chiffrement TLS aux connexions HTTP. Quand vous visitez https://example.com, votre navigateur utilise le protocole TLS pour chiffrer le trafic HTTP. HTTPS n’est pas un protocole séparé de TLS — c’est HTTP qui s’exécute dans un tunnel TLS.
Qu’est-ce que l’attaque POODLE ?
POODLE (Padding Oracle On Downgraded Legacy Encryption) a été découvert par Google en octobre 2014. Il exploitait une faille dans le padding des chiffrements CBC de SSL 3.0. L’attaque permettait à un attaquant sur le même réseau de déchiffrer des octets individuels du trafic chiffré. Comme la faille était dans la conception du protocole (pas dans une implémentation spécifique), SSL 3.0 ne pouvait pas être corrigé — il devait être abandonné entièrement. C’était le clou final dans le cercueil de SSL.