Voici une question qui mérite réflexion : si SSL n’existe plus depuis des années, pourquoi l’ensemble du secteur continue-t-il à parler de «SSL» chaque jour ? Vous achetez un « certificatSSL », configurez des « paramètresSSL » et consultez les pages des fournisseurs consacrées à la « sécuritéSSL », alors que le protocole qui assure réellement le fonctionnement est très certainement TLS. La distinction entre SSL et TLS est devenue l’une des bizarreries terminologiques les plus tenaces dans le domaine de la cybersécurité.
Le fond prime sur la forme. Leprotocole SSL (Security Socket Layer,SSL) a été officiellement abandonné dès 2015, et dès 2020, toutes les versions d’ SSL avaient disparu des navigateurs et serveurs pris en charge. Les certificats que les autorités de certification commercialisent sous l’appellation « certificatsSSL » sont en réalité des certificatsTLS (Transport Layer Security,TLS). Le nom est resté, mais pas le protocole.
Cet article passe outre les définitions théoriques et va droit au but : ce dont les équipes de sécurité ont réellement besoin. Nous allons clarifier les véritables différences entre les deux protocoles, expliquer pourquoi le manque de cohérence terminologique peut fausser votre posture de sécurité, et présenter les mesures que votre équipe devrait prendre dès aujourd'hui. Les deux protocoles s'appuient sur des certificats X.509 pour authentifier les terminaux et établir la confiance ; le vocabulaire que vous utilisez détermine donc votre niveau de compréhension des systèmes que vous exploitez.
Un bref historique : de « SSL » à TLS
Netscape, un navigateur Internet très populaire dans les années 1990, a créé le protocole SSL afin de sécuriser les premières transactions sur le Web. La version 1.0 de SSL n’a jamais été commercialisée en raison de graves failles de sécurité. La version 2.0 de SSL est apparue en 1995, mais présentait elle aussi des faiblesses. La version 3.0 de SSL a suivi en 1996, avant d’être officiellement abandonnée en 2015.
Lorsque le protocole a eu besoin d’un cadre normalisé et indépendant des fournisseurs, l’Internet Engineering Task Force (IETF) a pris le relais. L’IETF a développé le protocole « TLS » pour succéder à SSL: la version TLS 1.0, lancée en 1999, s’appuyait sur SSL 3.0 mais n’était délibérément pas interopérable avec celle-ci. TLS La version 1.1 a vu le jour en 2006, TLS la version 1.2 en 2008, et enfin TLS la version 1.3 en 2018, après environ 30 projets de l’IETF. Le nombre élevé de projets reflète l’évolution entreprise par TLS, qui a permis de corriger et de renforcer le protocole face aux multiples vulnérabilités découvertes au fil des ans. Parmi ces vulnérabilités, on peut citer les attaques par remplissage et par rétrogradation, Poodle, Heartbleed, etc.
Le nettoyage qui s'en est suivi a été décisif. Microsoft, Apple, Google, Mozilla, Cloudflare et Cisco ont tous abandonné les versions 1.0 et 1.1 de « TLS » d'ici mars 2020. Aujourd'hui, seules les versions 1.2 de « TLS » et 1.3 de « TLS » sont encore activement utilisées, et toutes les versions antérieures constituent désormais un risque plutôt qu'une option héritée.
Dix différences techniques majeures entre SSL et TLS
Ces protocoles présentent des similitudes générales, mais leurs mécanismes internes divergent d’une manière qui a une incidence directe sur la sécurité. Le tableau ci-dessous résume dix différences clés, suivies d’une analyse plus approfondie de chacune d’entre elles, allant de la conception générale SSL à la version la plus récente TLS 1.3.
| SSL | TLS (1.3) | |
|---|---|---|
| Perfect Forward Secrecy (secret parfait) | Jamais obligatoire | Obligatoire (à une seule exception près) |
| AEAD | Jamais | Obligatoire |
| Algorithmes | Algorithmes peu sûrs, notamment MD5, SHA-1 et DES | Des algorithmes modernes et robustes, notamment SHA-2 et AES |
| Messages d'alerte | Envoyé sans cryptage dans les premières versions | Crypté, avec signalement des erreurs |
| Fonctions de dérivation de clés | Ajouter des fonctions de dérivation de clés (KDF) ad hoc, souvent basées sur des algorithmes spécifiques | Utilise des KDF modernes dotés de garanties de sécurité solides |
| Attaques par gonflement de la longueur de données sur RSA | Autorise les versions de RSA vulnérables aux attaques par remplissage | N'autorise pas les versions de RSA vulnérables aux attaques par remplissage |
| Protection contre les attaques par dégradation et par substitution | Vulnérable à bien des égards aux attaques par déclassement et par substitution | Dispose de nombreux mécanismes de protection contre les dégradations, notamment des transcriptions qui relient de manière cryptographique chaque étape du protocole |
| PQC | Le PQC ne fera jamais l'objet d'une normalisation pour SSL | Les normes PQC sont en cours d'élaboration |
| Protocole d'enregistrement | Protocole d'enregistrement propre à Netscape | Protocole d'enregistrement normalisé par l'IETF |
| Simplifié | 2 RTT | 1 RTT |
 
Perfect Forward Secrecy (secret parfait)
SSL On protégeait généralement une session en chiffrant sa clé à l’aide de la clé à long terme du serveur. Quiconque parvenait par la suite à se procurer cette clé à long terme pouvait alors déchiffrer toutes les conversations enregistrées, même celles datant de plusieurs années. TLS La version 1.3 exige une nouvelle clé à usage unique pour chaque connexion, qui est supprimée dès que la connexion prend fin. Le vol de la clé privée d’un serveur reste un risque grave, mais il ne permet plus d’accéder au trafic passé.
AEAD
SSL le chiffrement des données et la vérification de leur intégrité se déroulaient en deux étapes distinctes, dans un ordre qui obligeait le destinataire à déchiffrer les données fournies par l'attaquant avant de pouvoir confirmer leur authenticité. Les attaquants ont appris à exploiter cette faille. La version 1.3 d'TLS n'autorise que les algorithmes de chiffrement qui effectuent ces deux opérations simultanément ; ainsi, toute donnée ne passant pas le contrôle d'intégrité est rejetée avant même d'être examinée.
Algorithmes
SSL Il reposait sur des algorithmes de chiffrement et des fonctions de hachage qui ont depuis été piratés, et comportait également des options délibérément affaiblies, héritées des règles d’exportation des années 1990. La version 1.3 d’ TLS les a toutes supprimées et ne propose plus qu’une liste restreinte d’algorithmes jugés fiables. L’intérêt réside justement dans ce menu plus restreint. Il n’y a désormais plus d’option vulnérable qu’un serveur mal configuré pourrait sélectionner.
Messages d'alerte
Lorsqu'une connexion SSL échouait, le message d'erreur était transmis en clair, ce qui permettait à toute personne surveillant le réseau de savoir exactement ce qui s'était passé. La version 1.3 d'TLS crypte ces messages presque instantanément, garantissant ainsi la confidentialité des échecs. En contrepartie, pour les administrateurs, une capture réseau ne suffit plus à elle seule à expliquer un échec, et le dépannage s'appuie désormais sur les journaux du client et du serveur.
Fonctions de dérivation de clés
Chaque connexion commence par un secret partagé unique et nécessite plusieurs clés distinctes dérivées de celui-ci. SSL utilisait une méthode maison pour cette étape, qui a fait ses preuves dans la pratique mais n’a jamais été étayée par aucune démonstration. TLS La version 1.3 utilise une méthode standard et bien étudiée, s’appuyant sur un argument de sécurité clair, et dérive chaque clé de manière à ce que la découverte de l’une d’entre elles ne révèle rien sur les autres.
Attaques par gonflement de la longueur de données sur RSA
Pendant des décennies, une utilisation particulière du protocole RSA présentait une faille connue qui permettait à un attaquant patient de récupérer la clé secrète au cœur d’une connexion. Des correctifs ont été appliqués à plusieurs reprises, mais ils ont été contournés à chaque fois. La version 1.3 d’ TLS a cessé d’appliquer des correctifs et a purement et simplement supprimé cette utilisation du protocole RSA. Le protocole RSA est toujours présent, mais uniquement pour vérifier l’identité, et uniquement sous une forme dont la sécurité a été rigoureusement démontrée.
Protection contre les attaques par dégradation et par substitution
Plusieurs des attaques les plus connues contre SSL n’ont jamais réussi à contourner la cryptographie. Elles s’inséraient au milieu d’une connexion et modifiaient discrètement la négociation initiale, amenant ainsi les deux parties à s’accorder sur un niveau de protection faible que chacune croyait avoir été demandé par l’autre. SSL n’a pas pu détecter cette altération. TLS 1.3 vérifie que les deux parties ont vu une négociation identique et non modifiée avant tout transfert de données réelles.
Cryptographie post-quantique
SSL est obsolète, et aucun travail supplémentaire ne sera effectué à ce sujet. TLS La version 1.3 a été conçue pour prendre en charge de nouveaux algorithmes sans nécessiter de nouvelle version du protocole, ce qui revêt une importance particulière à l'heure où la cryptographie résistante à l'informatique quantique fait son apparition. L'échange de clés post-quantique est déjà intégré dans les navigateurs grand public. Les certificats post-quantique constituent l'étape restante la plus difficile, principalement parce que les nouvelles clés et signatures sont beaucoup plus volumineuses.
Protocole d'enregistrement
SSL Il s'agissait auparavant d'une spécification propre à une entreprise, révisée chaque fois que celle-ci le décidait. Depuis que la responsabilité a été transférée à un organisme de normalisation ouvert, chaque version a fait l'objet d'un examen public par les développeurs de l'software , ainsi que d'une analyse indépendante menée par des chercheurs avant sa publication. La version 1.3 d'TLS masque également davantage la structure interne d'une connexion aux yeux de quiconque observe le réseau.
Allers-retours de la procédure de négociation de connexion
Avant qu’une connexion SSL ne puisse transmettre ne serait-ce qu’un seul octet de données réelles, les deux parties devaient échanger deux séries complètes de messages. La version 1.3 de « TLS » réorganise cet échange initial de manière à ce qu’une seule série suffise. Sur une connexion mobile lente, le gain en temps d’aller-retour se traduit par une charge plus rapide de la page.
TLS TLS ion 1.2 par rapport à la ion 1.3 : ce qui a changé
Étant donné que les versions 1.2 de « TLS » et 1.3 de « TLS » sont toutes deux encore largement utilisées, il est indispensable, d’un point de vue pratique, de bien comprendre les différences entre ces deux versions ; il ne s’agit pas là d’un simple exercice théorique. Trois changements retiennent particulièrement l’attention.
Performances améliorées lors de l'établissement de la connexion
TLS La version 1.3 réduit la procédure d'établissement de la connexion à un seul aller-retour, contre deux dans la version 1.2 d'TLS . La réduction du nombre d'allers-retours se traduit par une établissement plus rapide de la connexion et un protocole HTTPS plus réactif pour les utilisateurs. La simplification de la procédure d'établissement de la connexion TLS est l'une des raisons les plus évidentes de privilégier la version 1.3 d'TLS pour vos nouveaux déploiements.
Confidentialité parfaite vers l'avant par défaut
Comme mentionné ci-dessus, la version 1.3 d’ TLS impose la confidentialité parfaite vers l’avant via Diffie-Hellman Ephemeral, alors que les versions antérieures la considéraient comme facultative. Le protocole génère une clé de session unique pour chaque session ; ainsi, la compromission d’une clé n’expose pas les autres. Cette conception limite l’ampleur des répercussions d’une faille et renforce la résistance aux attaques par force brute et aux attaques de type « homme du milieu ».
Suppression des algorithmes cryptographiques obsolètes
TLS La version 1.3 est fournie avec une suite de chiffrement simple qui ne comprend que des algorithmes ne présentant aucune vulnérabilité connue. À l’inverse, la version 1.2 de « TLS » autorise encore certains algorithmes de chiffrement faibles, ce qui élargit la surface d’attaque et complique la configuration. Selon le NIST, les serveurs et clients d’ TLS s gouvernementaux doivent prendre en charge la version 1.2 de « TLS » avec des suites de chiffrement conformes à la norme FIPS, et le NIST recommande aux organisations d’élaborer des plans de migration vers la version 1.3 de « TLS ».
Chiffrement authentifié avec données associées (AEAD)
TLS Jusqu’à la version 1.2, le chiffrement et l’authentification étaient traités comme des opérations distinctes, le MAC étant généralement appliqué avant le chiffrement. Cet ordre obligeait les destinataires à traiter le texte chiffré contrôlé par l’attaquant avant de le vérifier, ce qui a donné lieu à une longue série d’attaques par oracle de remplissage. TLS La version 1.3 n’autorise plus que les algorithmes AEAD, qui associent confidentialité et intégrité en une seule primitive sous une seule clé et suppriment totalement la composition.
Pourquoi l'expression «SSL» persiste-t-elle (et dans quels cas pose-t-elle de réels problèmes) ?
Le terme «SSL» perdure pour une raison simple : il est profondément ancré dans les interfaces des produits, la documentation et les supports marketing des fournisseurs. Des bibliothèques cryptographiques telles qu’OpenSSL et WolfSSL portent toujours ce nom. Les écrans de configuration continuent d’intituler certains champs «SSL », les bases de connaissances font toujours référence à la «SSL setup », et les pages commerciales vantent toujours les «SSL certificates ». Ces termes sont devenus interchangeables dans l’usage courant, même si le protocole sous-jacent est l’ TLS.
La plupart du temps, il s’agit d’une simplification inoffensive. Les problèmes commencent lorsque l’étiquette et la réalité divergent au point d’influencer les décisions. Une équipe peut croire qu’elle utilise «SSL» alors que ses serveurs négocient en réalité le protocole TLS 1.2, ce qui fausse toute évaluation honnête du niveau de sécurité.
La conformité ajoute une complication supplémentaire. Les auditeurs signalent parfois des références «SSL» dans la documentation décrivant les configurations d’ TLS , ce qui oblige les équipes à passer du temps à harmoniser la terminologie avec la mise en œuvre. C’est dans l’écart entre ce que l’on appelle un système et ce qu’il exécute réellement que la confusion et les risques s’accumulent insidieusement.
L'avenir de l'TLS: durée de vie réduite et préparation à l'ère post-quantique
La prochaine question importante est la suivante : « Comment gérer l’ TLS e à grande échelle alors que le contexte évolue ? » Deux facteurs sont en train de redéfinir le paysage : la réduction spectaculaire de la durée de validité des certificats et l’avènement de la cryptographie post-quantique.
Modifications concernant la durée de validité des certificats
Le CA/Browser Forum a décidé de réduire la durée de validité des certificats « TLS » selon un calendrier précis : 200 jours d’ici 2026, 100 jours d’ici 2027 et 47 jours d’ici 2029. À mesure que ces durées diminuent, le volume des renouvellements est multiplié par huit environ, et le suivi manuel devient impossible. Se préparer à des durées de validité de 47 jours implique de considérer le renouvellement comme un processus automatisé et permanent, plutôt que comme un simple rappel de calendrier.
Cryptographie post-quantique
Le protocole « TLS » actuel n’a pas été conçu pour résister aux attaques quantiques, et l’échange de clés au cours de la procédure d’établissement de la connexion constitue l’élément le plus vulnérable. La préoccupation majeure concerne l’attaque de type « harvest-now-decrypt-later » (HNDL), dans laquelle les attaquants capturent aujourd’hui le trafic chiffré pour le déchiffrer une fois que les ordinateurs quantiques auront atteint leur maturité. En réponse, le secteur s’oriente vers la cryptographie post-quantique (PQC), où les futures procédures d’établissement de connexion remplaceront l’échange de clés classique, comme le RSA, par des mécanismes d’encapsulation de clés (KEM).
Les normes sont déjà en place. Le NIST a finalisé ses premières normes PQC, les FIPS 203, 204 et 205, publiées en août 2024. L'échange de clés PQC hybride fonctionne déjà sur la version actuelle d'TLS e 1.3 grâce à de nouveaux groupes d'échange de clés plutôt qu'à une nouvelle version du protocole, et le projet de l'IETF définit les mécanismes X25519MLKEM768, SecP256r1MLKEM768 et SecP384r1MLKEM1024 comme des mécanismes hybrides pour l'TLS e 1.3.
L'adoption de ces technologies progresse plus rapidement que beaucoup ne le pensent. Une étude réalisée en 2026 a révélé qu'environ 49 % des domaines analysés présentaient une préparation partielle à l'ère post-quantique grâce à l'échange de clés hybride, rendu possible par l'intégration du protocole ML-KEM-768 dans les navigateurs, les plateformes cloud et les réseaux de diffusion de contenu (CDN). Les organisations devraient dès à présent se préparer à adopter des modèles de certificats hybrides prenant en charge à la fois les algorithmes classiques et post-quantiques.
Bien que la version 1.2 d’ TLS soit encore prise en charge dans de nombreux environnements, le passage à la version 1.3 d’ TLS constitue la prochaine étape permettant de renforcer la sécurité et de pérenniser votre infrastructure. Tous les mécanismes en cours de normalisation pour l’ TLS post-quantique ne concernent que la version 1.3, ce qui exclut totalement la version 1.2 d’ TLS du processus de migration.
Comment Keyfactor vous aider
Passer d’une approche de type «SSL» à de véritables opérations de gestion des certificats ( TLS ) ne se résume pas à renommer un champ dans votre documentation. Keyfactor offre aux équipes de sécurité la plateforme nécessaire pour gérer les certificats à grande échelle alors que leur durée de vie diminue, et pour se préparer en toute confiance à la transition vers l’ère post-quantique.
Automatisation du cycle de vie des certificats grâce à Keyfactor Command offre une visibilité de bout en bout et un renouvellement automatisé, ce qui devient essentiel à mesure que les cycles se raccourcissent pour atteindre 47 jours. Sa plateforme d’ PKI moderne, EJBCAPKI , offre une gestion des certificats de niveau entreprise qui prend en charge la flexibilité cryptographique et les protocoles d’ SSL standard pour émettre à grande échelle des certificats « TLS ». Lafonctionnalité de découverte et d’inventaire cryptographiquesrecense automatiquement tous les actifs cryptographiques, ce qui vous permet d’évaluer votre préparation à l’ère quantique et d’éliminer les configurations d’ héritées qui persistent.
La gestion automatisée du cycle de vie des certificats transforme un casse-tête en matière de conformité en une opération reproductible. Demander une démo pour découvrir comment Keyfactor vous aide à abandonner les idées reçues de l'ère SSL et à exploiter TLS conformément aux exigences actuelles en matière de sécurité.
Vous vous posez des questions sur « SSL » et « TLS » ? Nous avons les réponses.
L'utilisation d'SSL est-elle toujours sûre ?
Non. Toutes les versions de SSL ont été dépréciées en raison de vulnérabilités connues, et SSL 3.0 a été retiré en 2015. Les navigateurs et serveurs modernes ne prennent plus en charge SSL; vous devriez donc utiliser TLS 1.2 ou 1.3.
Les certificats « SSL » et « TLS » sont-ils identiques ?
Dans la pratique, oui. Les fournisseurs et les autorités de certification qui commercialisent des« certificatsSSL » vendent en réalité des certificats TLS . Le terme continue d’être utilisé comme abréviation, mais le protocole qui sécurise votre connexion est TLS.
Quelle est la version la plus sécurisée d'TLS , actuellement disponible ?
TLS 1.3. Elle supprime les algorithmes obsolètes, applique par défaut la confidentialité parfaite vers l'avant et réduit la procédure d'établissement de la connexion à un seul aller-retour. Cette combinaison en fait l'option la plus sûre et la plus efficace actuellement disponible.
Dois-je migrer d'TLS s 1.2 vers TLS 1.3 ?
TLS 1.2 reste largement utilisé et sécurisé lorsqu'il est correctement configuré, mais TLS 1.3 améliore à la fois les performances et la sécurité. Le NIST recommande d'élaborer des plans de migration ; il est donc conseillé de privilégier TLS 1.3 pour les nouveaux déploiements.
Quel est l'impact de la réduction de la durée de validité des certificats sur la gestion des certificats SSL/TLS ?
Le CA/Browser Forum prévoit de réduire la durée de validité maximale à 47 jours d'ici 2029, ce qui multipliera par huit environ la fréquence des renouvellements. À ce rythme, la gestion manuelle devient impossible, rendant indispensable la gestion automatisée du cycle de vie des certificats.
Que signifie la cryptographie post-quantique pour TLS?
Les ordinateurs quantiques pourraient, à terme, venir à bout des algorithmes utilisés aujourd’hui dans la procédure d’authentification de TLS . Le secteur est en train d’intégrer des algorithmes résistants à l’informatique quantique ; les organisations doivent donc dresser l’inventaire de leurs actifs cryptographiques et prévoir des modèles de certificats hybrides prenant en charge à la fois les algorithmes classiques et post-quantiques.
Pourquoi les navigateurs affichent-ils toujours «SSL» dans leurs paramètres de sécurité ?
Il s'agit d'une appellation héritée. Les navigateurs et les outils font référence à SSL par habitude, mais le protocole qui sécurise la connexion est TLS. Si vous constatez une connexion HTTPS sécurisée, celle-ci utilise TLS.
Comment puis-je savoir quelle version d'TLS est utilisée par mon serveur ?
Utilisez des outils en ligne de type command, tels qu'OpenSSL, ou un service de test en ligne. La commande « openssl s_client -connect yourdomain.com:443 » affiche la version d'TLS et la suite de chiffrement négociées.
