Depuis plus de trente ans, les protocoles SSL et TLS protègent des milliards de transactions en ligne. Ce qui a commencé comme un ambitieux projet de sécurité de Netscape en 1994 a évolué vers les normes de cryptage sophistiquées d’aujourd’hui. L’histoire de SSL s’étend sur six versions majeures du protocole, d’innombrables améliorations de la sécurité et un changement fondamental dans la façon dont nous envisageons la sécurité sur le web.
Comprendre les versions SSL/TLS, ce n’est pas seulement savoir quels protocoles sont obsolètes. Il s’agit de savoir comment chaque vulnérabilité, attaque et avancée a façonné le paysage actuel où TLS 1.3 sécurise 95 % du trafic web crypté.
Table des matières
- Naissance du protocole SSL chez Netscape
- SSL 3.0 – Une refonte complète du protocole
- TLS 1.0 – L’ère de la normalisation IETF
- TLS 1.1 et TLS 1.2 – Améliorations progressives de la sécurité
- TLS 1.3 – La norme de sécurité moderne
- Idées reçues sur le versionnage SSL/TLS
- Le rôle des autorités de certification dans l’évolution de SSL/TLS
- Les grandes étapes de l’industrie qui ont façonné l’adoption du HTTPS
- Principales failles de sécurité à l’origine de l’évolution des protocoles
- L’avenir des protocoles SSL/TLS
Economisez 10% sur les certificats SSL en commandant chez SSL Dragon aujourd’hui !
Délivrance rapide, cryptage puissant, confiance de 99,99 % du navigateur, assistance dédiée et garantie de remboursement de 25 jours. Code de coupon : SAVE10
Naissance du protocole SSL chez Netscape
SSL 1.0 – La première tentative inédite (1994)
Taher Elgamal, scientifique en chef de Netscape, a conçu le protocole original Secure Sockets Layer en 1994. Mais SSL 1.0 n’a jamais vu le jour. Les chercheurs en sécurité de Netscape ont découvert des failles critiques avant la publication, des failles suffisamment graves pour que la version entière soit abandonnée.
La leçon était claire : les protocoles cryptographiques doivent faire l’objet d’un examen approfondi avant d’être déployés. Ce revers, bien que frustrant, a permis d’établir un modèle de tests rigoureux qui allait définir le développement futur de SSL et TLS.
SSL 2.0 – Première version publique (1995)
Quand le SSL est-il apparu ? La réponse est février 1995, lorsque Netscape a intégré SSL 2.0 à Navigator 1.1. Cette version de SSL introduisait des concepts fondamentaux encore utilisés aujourd’hui : la poignée de main SSL les certificats numériquesX.509 et l’authentification du serveur.
Mais SSL 2.0 présentait des problèmes. Il s’appuyait sur MD5 pour l’authentification des messages, utilisait la même clé pour le cryptage et l’authentification, et manquait de protection pour la poignée de main elle-même. Les attaquants pouvaient rétrograder les connexions vers un cryptage plus faible de 40 bits sans qu’aucune des parties ne s’en aperçoive.
L’IETF a officiellement abandonné SSL 2.0 en mars 2011 par le biais de la RFC 6176. À cette date, la plupart des serveurs étaient déjà passés à autre chose.
SSL 3.0 – Une refonte complète du protocole
Améliorations majeures par rapport à SSL 2.0 (1996)
Paul Kocher, Phil Karlton et Alan Freier ont entièrement réécrit le protocole SSL pour la version 3.0, publiée en novembre 1996. Ils ont séparé la couche de transport de données de la couche de messages, ajouté la prise en charge de l’échange de clés Diffie-Hellman et des suites de chiffrement Fortezza, et mis en œuvre une clé de 128 bits appropriée.
SSL 3.0 a également introduit la compression des enregistrements et une négociation plus souple de la suite de chiffrement. L’IETF l’a ensuite documenté dans la RFC 6101, reconnaissant ainsi son importance historique. Pendant près de vingt ans, SSL 3.0 a servi d’option de repli pour les systèmes existants.
La vulnérabilité POODLE et la dépréciation de SSL 3.0
En octobre 2014, l’équipe de sécurité de Google a découvert le fichier POODLE (Padding Oracle on Downgraded Legacy Encryption). L’attaque exploite la façon dont SSL 3.0 gère le remplissage en mode CBC (cipher block chaining). Les attaquants pouvaient décrypter les cookies HTTP sécurisés en forçant les navigateurs à passer de TLS à SSL 3.0.
L’IETF a réagi rapidement en supprimant SSL 3.0 en juin 2015 par le biais de la RFC 7568. Cela a marqué la fin de l’ère SSL. Lorsque les gens demandent quelle est la« dernière version de SSL« , la réponse est SSL 3.0, car SSL lui-même n’a plus jamais été mis à jour. Le flambeau est passé à Transport Layer Security.
TLS 1.0 – L’ère de la normalisation IETF
Passage de SSL à TLS (1999)
À la fin des années 1990, l’IETF a voulu normaliser les protocoles de sécurité de l’internet. Tim Dierks et Christopher Allen ont dirigé les efforts visant à transformer le protocole SSL en une norme ouverte. Microsoft et Netscape ont négocié la dénomination – TransportLayer Security est le compromis qui s’est imposé.
TLS 1.0, publié comme RFC 2246 en janvier 1999, était essentiellement SSL 3.1 avec un nouveau nom. Les différences étaient mineures mais suffisamment significatives pour rompre la compatibilité. Vous ne pouviez pas mélanger des clients SSL 3.0 avec des serveurs TLS 1.0 sans une mise en œuvre minutieuse.
Principales différences par rapport à SSL 3.0
TLS 1.0 a mis à jour la cryptographie sous-jacente. Il a remplacé le code d’authentification des messages (MAC) personnalisé de SSL par le code HMAC, normalisé par les cryptographes. La fonction de dérivation des clés a été modifiée pour empêcher certaines attaques théoriques. Le système d’alerte s’est enrichi de codes d’erreur plus spécifiques.
TLS 1.0 a également exigé la prise en charge des suites de chiffrement DSS/DH, ce qui a donné plus de souplesse aux implémentations. Ces changements semblent mineurs, mais ils reflètent le passage d’un développement propriétaire à une normalisation pilotée par la communauté. L’IETF contrôlait désormais l’évolution du protocole.
TLS 1.1 et TLS 1.2 – Améliorations progressives de la sécurité
Protection de TLS 1.1 contre les attaques CBC (2006)
Publié en avril 2006 par le biais de la RFC 4346, TLS 1.1 a corrigé des vulnérabilités CBC spécifiques. Le changement le plus important ? Les vecteurs d’initialisation (IV) explicites ont remplacé les IV implicites. Cela a empêché les attaquants de prédire l’IV et d’exploiter le chaînage de blocs de chiffrement.
TLS 1.1 a également amélioré la gestion des erreurs pour les enregistrements avec remplissage. Au lieu de révéler des erreurs de remplissage spécifiques, il renvoie une alerte générique bad_record_mac. Ces modifications ont permis de se prémunir contre BEAST (Browser Exploit Against SSL/TLS), découvert des années plus tard, en 2011.
Les registres de paramètres de l’IANA ont été établis, ce qui a permis de mieux organiser la gestion des suites de chiffrement. Mais l’adoption a été lente. De nombreuses organisations ont entièrement ignoré TLS 1.1, attendant les améliorations plus substantielles de TLS 1.2.
Flexibilité accrue de TLS 1.2 (2008)
Quand TLS 1.2 a-t-il été publié ? Août 2008, via la RFC 5246. Cette mise à jour a apporté les changements les plus importants depuis SSL 3.0. Le protocole est passé de combinaisons MD5/SHA-1 codées en dur à des fonctions pseudo-aléatoires (PRF) spécifiées par la suite de chiffrement. SHA-256 est devenu la nouvelle norme.
TLS 1.2 a introduit des modes de chiffrement authentifiés avec données supplémentaires (AEAD), notamment AES-GCM et ChaCha20-Poly1305. Il a donné aux implémentations une certaine flexibilité dans le choix des algorithmes de hachage et de signature. Cette adaptabilité s’est avérée cruciale au fur et à mesure de l’évolution des normes cryptographiques.
Le protocole reste largement déployé aujourd’hui. Environ 95,8 % des sites web prennent encore en charge TLS 1.2, souvent en parallèle avec TLS 1.3. En mars 2021, l’IETF a rendu TLS 1.0 et 1.1 obsolètes par le biais de la RFC 8996, faisant de TLS 1.2 la norme minimale acceptable.
Economisez 10% sur les certificats SSL en commandant chez SSL Dragon aujourd’hui !
Délivrance rapide, cryptage puissant, confiance de 99,99 % du navigateur, assistance dédiée et garantie de remboursement de 25 jours. Code de coupon : SAVE10
TLS 1.3 – La norme de sécurité moderne
Cinq ans de développement (2018)
TLS 1.3 a mis une décennie à arriver. L’IETF a publié le RFC 8446 en août 2018 après 28 versions préliminaires et une collaboration intensive. La simplicité et la performance ont été les moteurs de la refonte. Le groupe de travail a supprimé les anciennes fonctionnalités, simplifié la poignée de main et éliminé des classes entières de vulnérabilités.
Google, Mozilla, Microsoft et Apple ont rapidement ajouté la prise en charge. En 2019, tous les principaux navigateurs pouvaient négocier des connexions TLS 1.3. Cloudflare et d’autres fournisseurs de CDN l’ont activé par défaut. La dernière version de TLS n’a pas seulement amélioré la sécurité, elle a rendu les connexions chiffrées plus rapides.
Améliorations révolutionnaires de la sécurité
TLS 1.3 a supprimé tout ce qui était cassé ou affaibli. Suites de chiffrement SHA-1, MD5, RC4, DES et 3DES ? Elles ont disparu. Échange de clés RSA et Diffie-Hellman statiques ? Éliminés. Le protocole exige désormais un parfait secret de transmission à l’aide de Diffie-Hellman éphémère pour toutes les connexions.
La poignée de main a changé fondamentalement. Chaque message après ServerHello est crypté, ce qui permet de dissimuler la négociation aux regards indiscrets. La fonction de dérivation de clé a été remplacée par une fonction d’extraction et d’expansion basée sur HMAC (HKDF), qui offre de meilleures garanties cryptographiques.
TLS 1.3 a également introduit le mode 0-RTT (zero round-trip time). Les clients peuvent envoyer des données chiffrées dès le premier message aux serveurs précédemment contactés, ce qui élimine le temps de latence de la poignée de main. La machine à états simplifiée a rendu les implémentations moins sujettes aux erreurs. L’ECC a été intégré à la spécification de base avec de nouveaux algorithmes de signature tels que RSA-PSS.
Adoption et coexistence actuelles
Quelle est la dernière version de TLS ? C’est TLS 1.3 qui détient ce titre. Mais TLS 1.2 n’est pas près de disparaître. Les organisations ont besoin de temps pour mettre à niveau les serveurs, tester la compatibilité et mettre à jour les logiciels clients. La plupart des sites soucieux de la sécurité prennent désormais en charge les deux versions, ce qui permet aux clients de choisir la meilleure option disponible.
La coexistence fonctionne bien. Les serveurs négocient la version la plus élevée supportée par les deux parties. Les clients qui ne peuvent pas gérer TLS 1.3 reviennent à TLS 1.2. Cette approche de migration progressive permet d’éviter les désastres de compatibilité qui ont affecté les transitions précédentes.
Idées reçues sur le versionnage SSL/TLS
Pourquoi il n’y a pas de TLS 2.0
Quelle est la date de publication de TLS 2.0 ? Il n’y en a pas. TLS 2.0 n’existe pas et n’existera jamais. L’IETF utilise une version incrémentale : TLS 1.0, 1.1, 1.2, 1.3. La prochaine version, si elle existe, sera TLS 1.4 ou peut-être TLS 2.0, mais passer directement à « TLS 2.0 » après SSL 3.0 aurait provoqué une confusion massive.
Les gens s’attendent souvent à ce que les protocoles utilisent des numéros de version majeurs (comme les logiciels qui passent de la version 1 à la version 2). Mais les protocoles cryptographiques évoluent de manière plus conservatrice, chaque version s’appuyant sur la précédente.
Terminologie SSL et TLS
Demandez un « certificat SSL » et vous obtiendrez un certificat qui fonctionne avec TLS 1.2 et TLS 1.3. L’industrie utilise toujours le terme « SSL » dans le marketing parce qu’il est familier. Même si la version actuelle de SSL est techniquement inexistante (SSL s’est arrêté à la version 3.0), le terme est resté.
Des autorités de certification comme DigiCert et Sectigo vendent des « certificats SSL » qui utilisent exclusivement les protocoles TLS. C’est déroutant mais inoffensif. Rappelez-vous simplement que lorsque quelqu’un mentionne SSL en 2026, il s’agit très certainement de TLS.
Le rôle des autorités de certification dans l’évolution de SSL/TLS
Types de validation Développement
Les premiers certificats SSL étaient coûteux et lents. La validation par l’entreprise nécessitait des jours ou des semaines de vérification manuelle. En 2002, GeoTrust a introduit la Validation de domainequi automatise le processus en vérifiant la propriété du domaine par le biais du courrier électronique ou des enregistrements DNS.
Extended Validation certificates arrived in 2007, promising the highest assurance with green address bars in browsers. Let’s Encrypt launched in 2015, offering free Domain Validation certificates through automated issuance. Cloudflare followed with their own free certificate program. These changes democratized HTTPS, making encryption accessible to small websites.
Réduction de la période de validité du certificat
Les périodes de validité des certificats n’ont cessé de se réduire. En 2015, les exigences de base ont ramené la durée de validité maximale de cinq à trois ans. En 2018, la limite a été fixée à deux ans. Le navigateur Safari d’Apple a imposé une durée maximale d’un an en 2020, obligeant les autres navigateurs à suivre le mouvement.
Aujourd’hui, l’industrie s’oriente vers des cycles de vie des certificats encore plus courts. Le CA/Browser Forum a défini une nette réduction des périodes de validité des certificats : 200 jours à partir du 15 mars 2026,100 jours à partir du 15 mars 2027 et seulement 47 jours d’ici au 15 mars 2029.
Cette évolution rend la gestion manuelle des certificats impraticable, poussant les organisations vers des solutions automatisées telles que le Certificate-as-a-Service (CaaS) basé sur ACME, où la validation, l’émission et le renouvellement sont gérés automatiquement.
Les grandes étapes de l’industrie qui ont façonné l’adoption du HTTPS
La poussée de Google vers le HTTPS
En août 2014, Google a annoncé que le protocole HTTPS était un signal de classement. Cette seule décision a changé l’histoire du SSL. Les webmasters qui ignoraient le cryptage ont soudain eu des raisons commerciales de s’en préoccuper. En 2016, la moitié du trafic web était chiffrée.
Chrome 68 est passé à l’étape suivante en juillet 2018, en marquant tous les sites HTTP comme « Non sécurisé. » L’avertissement est apparu dans la barre d’adresse pour chaque page non cryptée. Aujourd’hui, plus de 95 % du trafic web utilise le protocole HTTPS. Google a transformé le chiffrement d’une meilleure pratique de sécurité en une exigence commerciale.
Évolution des indicateurs de sécurité des navigateurs
Vous vous souvenez de la barre d’adresse verte d’Extended Validation ? Elle a disparu. Chrome l’a supprimée en 2020 après que des études ont montré que les utilisateurs ne la remarquaient pas ou ne la comprenaient pas. L’icône du cadenas elle-même disparaît, remplacée par des indicateurs neutres qui normalisent HTTPS au lieu de le récompenser.
Chrome 69 a supprimé le texte « Secure », ne laissant que le cadenas. Les navigateurs actuels mettent l’accent sur l’avertissement concernant les connexions non sécurisées plutôt que sur la promotion des connexions sécurisées. Le message : HTTPS est une attente par défaut, pas quelque chose de spécial.
Principales failles de sécurité à l’origine de l’évolution des protocoles
Attaques notables contre SSL/TLS
POODLE a frappé SSL 3.0 en 2014, exploitant les vulnérabilités de l’oracle de remplissage en mode CBC. Les attaquants pouvaient décrypter les cookies sécurisés en rétrogradant les connexions et en modifiant de manière répétée le texte chiffré. L’attaque a tué SSL 3.0 en quelques mois.
BEAST a ciblé TLS 1.0 en 2011, en utilisant une faiblesse CBC similaire. Les attaquants pouvaient décrypter les cookies HTTPS en injectant du code côté client et en observant les réponses chiffrées. La solution consistait à implémenter des IV explicites dans TLS 1.1.
BREACH a abusé de la compression HTTP en 2013. L’attaque ne visait pas le protocole TLS lui-même, mais montrait comment les décisions prises au niveau de la couche applicative affectent la sécurité. Heartbleed, découvert en 2014, a mis en évidence une faille critique du protocole OpenSSL qui a entraîné la fuite de clés privées et de données d’utilisateurs.
Enseignements tirés
Chaque vulnérabilité a mis en évidence le même point : la rétrocompatibilité est dangereuse. Le maintien en vie d’anciens protocoles pour les systèmes existants crée des vecteurs d’attaque. L’industrie a donc appris à procéder à une dépréciation agressive et à forcer les mises à jour.
Les chercheurs en sécurité méritent également d’être félicités. La divulgation publique des vulnérabilités a accéléré les améliorations. Sans POODLE, SSL 3.0 pourrait encore se cacher dans des configurations de serveurs aujourd’hui.
L’avenir des protocoles SSL/TLS
Cryptographie post-quantique
Les ordinateurs quantiques menacent les algorithmes de chiffrement actuels. La cryptographie RSA et la cryptographie à courbe elliptique pourraient devenir obsolètes lorsque les machines quantiques atteindront une échelle suffisante. Le NIST normalise des algorithmes post-quantiques conçus pour résister aux attaques quantiques.
Le protocole TLS devra être mis à jour pour prendre en charge ces algorithmes résistants à la quantification. La transition ne sera pas facile, car la cryptographie post-quantique utilise des clés plus grandes et des approches mathématiques différentes. Mais l’évolution du protocole qui nous a permis de passer de SSL 2.0 à TLS 1.3 a prouvé que la communauté peut gérer des transitions majeures.
Technologies émergentes
DTLS (Datagram Transport Layer Security) étend TLS aux connexions UDP. QUICdéveloppé par Google et normalisé par l’IETF, intègre le chiffrement directement dans la couche transport. Ces protocoles s’appuient sur les fondements cryptographiques de TLS tout en s’adaptant à différents cas d’utilisation.
Des alternatives basées sur la blockchain comme Remme expérimentent la PKI distribuée. Les autorités de certification continuent d’évoluer, en automatisant davantage de processus et en prenant en charge des périodes de validité plus courtes. Que se passera-t-il après TLS 1.3 ? Probablement des améliorations progressives plutôt qu’une refonte complète. TLS 1.3 a réussi la plupart des choses.
Restez à jour avec les certificats TLS 1.3 de SSL Dragon
Comprendre l’évolution des protocoles est une chose. Mettre en œuvre des normes de cryptage modernes en est une autre. SSL Dragon fournit des certificats numériques entièrement compatibles avec TLS 1.3 et TLS 1.2, supportant les derniers protocoles cryptographiques et suites de chiffrement.
Nous offrons une émission rapide, un cryptage puissant et une confiance de 99,99 % dans les navigateurs grâce à des partenariats avec les principales autorités de certification, notamment DigiCert, Sectigo et GeoTrust. Nos solutions de gestion automatisée des certificats vous aident à gérer les cycles de vie de 47 jours à venir sans avoir à vous préoccuper des renouvellements manuels.
Vous passez d’un protocole obsolète à un autre ? Notre équipe d’assistance spécialisée vous guide tout au long de la transition. Chaque achat est assorti d’une garantie de remboursement de 25 jours. Découvrez dès aujourd’hui notre portefeuille de certificats et sécurisez votre infrastructure avec la dernière version de TLS.
Economisez 10% sur les certificats SSL en commandant aujourd’hui!
Émission rapide, cryptage puissant, confiance de 99,99 % du navigateur, assistance dédiée et garantie de remboursement de 25 jours. Code de coupon: SAVE10
