- Le protocole SSL est apparu au milieu des années 1990, dans le contexte de la rivalité entre navigateurs menée par Netscape et Microsoft
- SSL 2 présentait des défauts cryptographiques et pratiques, sur la base desquels Microsoft a introduit le protocole PCT
- En réponse, Netscape a développé SSL 3.0 pour tenter de reprendre l’initiative
- L’industrie et la communauté souhaitaient préserver la compatibilité entre navigateurs et ont confié à l’IETF le rôle de normalisation
- C’est dans ce processus que le nom du protocole est devenu TLS 1.0, appellation qui perdure encore aujourd’hui
Contexte : guerre des navigateurs et naissance des protocoles de sécurité
- Au milieu des années 1990, Netscape et Microsoft se livraient une concurrence acharnée sur le marché des navigateurs
- C’est dans cette rivalité que Netscape a développé le protocole SSL
SSL 2 et ses problèmes
- La toute première version de SSL n’a pas été commercialisée, car elle a été rapidement neutralisée par des failles cryptographiques
- La version effectivement déployée, SSL 2, a été utilisée pendant quelques années, mais elle comportait plusieurs défauts cryptographiques et pratiques
- Ces défauts n’ont pas provoqué immédiatement de crise critique, mais la nécessité d’améliorations a continué à être soulevée
La réponse de Microsoft : le protocole PCT
- Avec l’intensification de la concurrence, Microsoft a ajouté ses propres fonctionnalités à SSL 2 et a introduit un protocole appelé PCT
- PCT n’était pris en charge que par Internet Explorer (IE) et IIS
La nouvelle stratégie de Netscape : SSL 3.0
- Netscape voulait lui aussi corriger les problèmes de SSL 2, mais ne souhaitait pas laisser Microsoft prendre l’avantage
- L’entreprise a donc développé SSL 3.0, en recherchant une évolution nettement distincte de l’existant
Négociations de normalisation dans l’industrie des navigateurs
- Les acteurs de l’industrie et de la communauté ne voulaient pas voir le protocole se scinder en deux (éviter un fork)
- Chez Consensus Development (où travaillait l’auteur), une réunion entre représentants de Netscape et de Microsoft a été organisée
- Bruce Schneier (avant qu’il ne devienne célèbre), Paul Kocher (concepteur de SSL 3) et Barbara Fox (représentante de Microsoft), entre autres, y ont participé
Normalisation par l’IETF et changement de nom
- Netscape comme Microsoft ont accepté que l’IETF (Internet Engineering Task Force) pilote le processus de normalisation du protocole
- L’auteur était chargé de l’édition du document de standardisation de l’IETF (RFC)
- Dans le cadre d’un compromis politique, il fallait apporter quelques modifications à SSL 3.0 et lui donner un nouveau nom (afin d’éviter l’impression que l’IETF « approuvait simplement » le protocole existant)
- C’est ainsi qu’est née l’appellation TLS 1.0, qui correspond en pratique à SSL 3.1
Mot de la fin
- Avec le recul, tout ce processus de discussion autour du nom et de la normalisation paraît quelque peu absurde
1 commentaires
Commentaires sur Hacker News
Explication d’une situation confuse où les numéros de version seuls ne permettent pas vraiment de comprendre à quel point les protocoles diffèrent. SSLv2 a été la première version de SSL largement utilisée, mais comportait plusieurs problèmes. SSLv3 était un protocole presque entièrement reconstruit. TLS 1.0 était très proche de SSLv3, mais a subi quelques petites révisions au cours du processus de normalisation par l’IETF. TLS 1.1 était une version de correction mineure destinée à résoudre des problèmes liés à l’utilisation des chiffrements par blocs dans TLS 1.0. TLS 1.2 a introduit des modifications d’ampleur moyenne pour suivre l’évolution de la cryptographie, avec la prise en charge de hachages plus récents (pour répondre aux vulnérabilités de MD5 et SHA-1) et l’ajout de suites AEAD (comme AES-GCM). TLS 1.3 est un protocole en grande partie réécrit, tout en reprenant certains éléments des versions antérieures à TLS 1.2. Chaque protocole a été conçu avec une négociation automatique de version afin que clients et serveurs puissent être mis à niveau indépendamment sans perte de connectivité.
En tenant compte du fait que Microsoft était à l’époque une entreprise complètement différente de celle d’aujourd’hui, cela ne semble même pas particulièrement étrange avec les critères actuels. À l’époque, « M$ » utilisait tous les moyens possibles pour freiner les technologies Internet open source, et cette attitude a perduré jusqu’au début des années 2010. J’ai le sentiment que cela a contribué à empêcher Java Applets d’évoluer et à leur éviction du marché. Le développement de JavaScript et de CSS a aussi semblé stagner pendant des années. Mon entreprise m’imposait de prendre en charge les technologies les plus récentes d’IE, mais j’ai choisi Mozilla 3.0 à la place, et après avoir corrigé des bugs JS, j’ai utilisé Mozilla pour le développement de SPA d’entreprise. Plus tard, même dans des entreprises du Fortune 500, l’adoption de Mozilla/Firefox pour les applications internes s’est élargie, et avec le recul c’était un bon choix.
Avis selon lequel on pourrait très bien revenir au nom SSL pour la prochaine version. L’argument est que tout le monde continue de toute façon à employer l’appellation « SSL ».
Mention qu’en pratique, le nom « TLS » est déjà utilisé à beaucoup d’autres endroits. D’où l’hésitation, car mettre à jour des configurations et des signatures de fonctions est extrêmement pénible.
Insistance sur le fait qu’il ne faut surtout donner cette idée à personne.
Lorsqu’on explique à quelqu’un comment sécuriser l’accès à un site web, donc quand on emploie la terminologie TLS/SSL, question sur le terme que chacun utilise habituellement. L’auteur ajoute aussi qu’il est curieux de connaître l’âge des répondants et de savoir s’ils travaillaient déjà avant 1999, en précisant qu’il donnera lui aussi sa réponse.
Je réponds SSL (27 ans). En revanche, dans le code j’utilise
tls, et dans la documentation je préfère écrire SSL/TLS pour éviter la confusion.Beaucoup de gens utilisent le terme SSL parce qu’ils implémentent les communications sécurisées avec des bibliothèques dont le nom contient ssl, comme OpenSSL. En dehors d’OpenSSL, il existe aussi BoringSSL, LibreSSL et wolfSSL. Les bibliothèques portant le nom TLS sont moins connues, par exemple GnuTLS, mbedTLS, s2n-tls et RustTLS.
La principale raison d’utiliser le terme SSL, c’est qu’il semble mieux compris. Techniquement, TLS est le terme correct (en pratique, plus personne n’utilise SSL 3.0), mais comme le terme SSL reste présent jusque dans les bibliothèques de référence, il continue d’être employé. J’ai appris l’appellation SSL à l’époque des crypto wars des années 1990, et je me souviens qu’il fallait télécharger illégalement la version Netscape « US only » pour avoir un vrai chiffrement SSL, donc j’utilise sans doute ce terme par simple habitude.
Moi, je dis généralement « https ». Les non-spécialistes en comprennent parfois au moins approximativement le sens, donc je préfère.
Je réalise pour la première fois que je ne faisais pas instinctivement une distinction correcte entre SSL et TLS. C’est assez fascinant de découvrir la vraie raison après 20 ans.
« Transport Layer Security » semble clairement être un meilleur nom. J’aime aussi le terme TLS. Enchaîner deux sons en S le rend presque amusant, comme un serpent.
Mais TLS est déjà largement utilisé pour « Thread Local Storage ». Transport Layer Security est officiel depuis 1999, mais Thread Local Storage existait déjà avant 1996 dans des environnements de développement MS ou IBM. Dans le monde Unix, il y a aussi le fait qu’on a plutôt privilégié le terme thread-specific data depuis l’arrivée de pthread en 1995. L’ABI Itanium de 2001 a peut-être aussi contribué à diffuser davantage « TLS », et Sun Microsystems utilisait peut-être déjà ce terme. Si quelqu’un a encore un manuel OS/2, les références seraient bienvenues.
À mon avis, c’est plutôt SSL qui serait le nom le plus approprié. En théorie, TLS devrait être un mécanisme de sécurité générique fonctionnant à plusieurs couches (par exemple intégrable avec IPSec), mais en pratique il est surtout utilisé uniquement pour les sockets TCP. Sa variante UDP est DTLS, et QUIC n’est pas inclus dans TLS lui-même. Il existe désormais aussi le TLS du noyau Linux et des infrastructures spécifiques à Windows, mais on ne l’active pas simplement comme un flag de socket. Et honnêtement, ce son de S « de serpent » a quand même de la classe.
« SSL » est plus facile à prononcer que « TLS ». Avec S-S-L, la langue bouge à peine, donc c’est plus rapide et naturel à dire.
Si Kaa du Livre de la jungle parlait de sécurité TCP, le nom S~S~L lui irait bien. En fait, ce serait même amusant d’ajouter encore un S et d’appeler ça SSSL.
Les gens qui tiennent absolument à distinguer strictement TLS et SSL veulent souvent montrer qu’ils connaissent bien la différence, ou aiment qu’on parle ainsi. Cette distinction ressemble un peu à celle entre .doc et .docx : techniquement ce n’est pas pareil, mais pour l’utilisateur moyen c’est presque compatible. La grande majorité des gens se moquent de la structure interne ou du fonctionnement exact tant que HTTPS marche correctement.
Lien connexe : partage d’un article de 1996 intitulé « Randomness and the Netscape Browser » (Dr. Dobb's Journal) https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.html Comme il date de 1996, le ton et le style sont très différents de ceux des articles ou papiers modernes. Ça donne un vrai coup de vieux.
Question sur le fait que TLS 1.0 n’aurait-il pas en réalité apporté beaucoup d’améliorations par rapport à SSL 3.0. L’article semble le présenter comme un simple « léger ajustement pour marquer la différence », d’où l’interrogation.
Sur Internet, plus de 300 000 services prennent encore en charge SSLv2. Lien : https://shodan.io/search/report/… Graphique d’évolution : https://trends.shodan.io/search?query=ssl.version%3Asslv2#overview Le chiffre a nettement diminué au fil des ans, mais il faudra encore du temps avant que cela disparaisse complètement.