Pourquoi SSL a été renommé TLS à la fin des années 1990

• Au milieu des années 1990, alors que la guerre des navigateurs faisait craindre une scission entre le SSL de Netscape et le PCT de Microsoft, l’industrie a cherché à les réunir dans un standard ouvert unique
• Les premières versions de SSL, entachées de défauts, n’ont pas pu être publiées, et la première version réellement utilisée, SSL 2, a bien été employée pendant quelques années, malgré ses limites cryptographiques et pratiques
• Le PCT de Microsoft était une extension maison, fondée sur SSL 2 et adaptée à IE et IIS, tandis que Netscape a réagi avec SSL 3.0 pour ne pas perdre le contrôle du standard
• Netscape et Microsoft se sont accordés sur une procédure de standardisation ouverte via l’IETF, mais il fallait éviter de donner l’impression que l’IETF entérinait simplement le protocole de Netscape
• Au final, SSL 3.0 a subi quelques modifications et a aussi changé de nom, et TLS 1.0 a en réalité démarré sous une forme très proche de SSL 3.1

---

SSL et PCT dans la guerre des navigateurs

• Au milieu des années 1990, la concurrence entre les navigateurs de Netscape et de Microsoft a aussi influencé la standardisation des protocoles de sécurité
• Netscape a développé le protocole SSL
  • Les premières versions ont été rapidement cassées en raison de failles cryptographiques et n’ont pas été publiées
  • La première version de production a été SSL 2, utilisée pendant quelques années
  • SSL 2 présentait des défauts cryptographiques et pratiques, sans pour autant constituer une crise si grave qu’un remplacement immédiat s’imposait
• Microsoft a modifié SSL 2 et y a ajouté ses propres extensions pour définir PCT
  • PCT est un protocole dérivé de SSL 2
  • Sa prise en charge se limitait à IE et IIS
• Netscape cherchait également à corriger les problèmes de SSL 2, mais ne voulait pas que Microsoft prenne le leadership ou la propriété du standard
  • Cela a conduit au développement de SSL 3.0, avec des changements plus importants

La standardisation à l’IETF et le nom TLS

• Plusieurs acteurs de l’industrie et de la communauté voulaient éviter que le protocole ne forke
• Consensus Development a organisé une réunion entre des représentants de Netscape et de Microsoft
  • Tim Dierks travaillait alors chez Consensus Development avec Christopher Allen
  • Dans le cadre d’un contrat avec Netscape, il a rédigé une implémentation de référence de SSL 3.0
  • Bruce Schneier a participé à la réunion, tout comme probablement Paul Kocher, concepteur du protocole SSL 3, et Microsoft y était représenté par Barbara Fox
• À l’issue des négociations, Microsoft et Netscape ont accepté que l’IETF reprenne le protocole et le standardise selon une procédure ouverte
  • Ce processus a conduit Tim Dierks à éditer la RFC
• Pendant la standardisation, quelques modifications ont été apportées à SSL 3.0
  • L’objectif était d’éviter que l’IETF donne l’impression de simplement entériner le protocole de Netscape
  • Pour la même raison, le nom du protocole a aussi été changé
• Le TLS 1.0 ainsi créé était en pratique une version très proche de SSL 3.1

[GN⁺]

Avis de Hacker News

• Les numéros de version ne reflètent pas bien les différences entre protocoles, ce qui rend tout encore plus confus
  SSLv2 a été le premier SSL largement déployé, mais il posait beaucoup de problèmes, et SSLv3 était presque un nouveau protocole
  TLS 1.0 ressemble à SSLv3, mais avec quelques corrections apportées pendant le processus de standardisation par l’IETF ; TLS 1.1 est une révision très mineure corrigeant un problème dans la manière d’utiliser les chiffrements par blocs
  TLS 1.2 est une révision de taille intermédiaire qui, pour répondre aux faiblesses de MD5 et SHA-1, a ajouté de nouveaux hachages et des suites de chiffrement AEAD comme AES-GCM ; TLS 1.3 réutilise certains éléments antérieurs à TLS 1.2, mais ressemble en grande partie à un nouveau protocole
  Tous ces protocoles ont été conçus pour pouvoir négocier automatiquement la version, afin que clients et serveurs puissent être mis à niveau indépendamment sans perdre la connectivité

  • TLS 1.0 a introduit la modularité via le concept d’« extensions », donc il est difficile d’y voir une évolution mineure
    L’une d’elles était les tickets de session, qui permettaient la reprise de session côté serveur sans état synchronisé entre serveurs ; une autre était Server Name Indication, qui permettait à un serveur d’utiliser plusieurs certificats
  • La négociation automatique de version a aussi rendu possibles, pendant des décennies, de nombreuses attaques par rétrogradation
  • Il aurait fallu l’appeler simplement TLS v4.0, et non TLS 1.0
    Le fait d’avoir ensuite créé les versions v1.1, v1.2 et v1.3 ressemble aussi à un entêtement visant à ne pas reconnaître que la remise à zéro du numéro de version était objectivement une erreur
  • Au moins, ils n’ont pas numéroté les versions avec des années

• Microsoft était alors une bête complètement différente, donc la confusion autour des noms SSL/TLS ne me paraît pas si étrange
  À cette époque, M$ cherchait à tout contrôler, et je pense qu’ils n’ont pas cessé d’essayer de freiner les technologies Internet open source avant le début des années 2010
  Ils ont réussi à tuer les applets Java, et je pense qu’ils ont aussi fait prendre plusieurs années de retard à JavaScript et à CSS dans leur ensemble
  Au début des années 2000, dans mon entreprise, on nous poussait à prendre en charge les dernières « technologies » d’IE, mais dès qu’un bug JS critique a été corrigé, nous avons immédiatement commencé à prendre en charge Mozilla 3.0 ; plus tard, cela s’est avéré être une bonne décision quand une entreprise du Fortune 500 s’est mise à utiliser Mozilla/Firefox pour ses applications internes bien avant que cela ne devienne courant

  • Je ne pense pas que ce soit Microsoft qui ait tué les applets Java
    Elles ont toujours fonctionné dans IE, et c’était quasiment le seul canal sur lequel Microsoft pouvait avoir de l’influence
    Les applets ont échoué en devenant l’exemple type de « Java est lent » ; même si ce n’était pas forcément vrai en général, ça l’était pour les applets à cause de l’attente du téléchargement et du démarrage de la JVM
    Au final, HTML/JS a fini par mieux gérer les fonctionnalités dynamiques qui nécessitaient auparavant des applets, et Flash a pris le reste des usages pour lesquels HTML ne suffisait pas, ce qui les a fait disparaître
  • Les applets sont mortes pour de nombreuses raisons
    Même pour une animation triviale, le temps de démarrage du JRE était absurdement long ; pour l’époque, les besoins mémoire et les plantages étaient importants, et les problèmes de compatibilité des premières versions de la plateforme Java étaient aussi étranges
    Le modèle de sécurité, fondé sur l’hypothèse que les acteurs capables d’obtenir un certificat d’une CA seraient bienveillants, était ridicule, et les technologies de sandboxing des navigateurs en général, pas seulement d’IE, étaient immatures
  • Je trouve que le surnom « M$ » convient encore mieux aujourd’hui
  • Microsoft n’a pas tant changé que ça, à part le fait que son service communication s’est amélioré
  • Amazon avait aussi https://github.com/aws/s2n-tls
    J’avais beaucoup d’attentes pour s2n, mais il semble ne jamais s’être vraiment imposé en dehors d’AWS

• Les personnes qui font une distinction forte entre TLS et SSL connaissent cette différence et considèrent que leur interlocuteur devrait aussi la connaître, mais en pratique c’est un peu comme la différence entre .doc et .docx
  C’est fondamentalement différent, mais pour un utilisateur ordinaire cela paraît interchangeable, et sur le terrain on se soucie surtout de savoir si HTTPS fonctionne, pas vraiment de ce qui se passe en interne

  • La principale difficulté était d’expliquer aux utilisateurs ordinaires que TLSv1.0 est plus récent et meilleur que SSLv2/SSLv3
    Je me souviens avoir eu pas mal de discussions avec des gens qui pensaient qu’un nombre plus élevé signifiait forcément mieux
  • Même si SSL est obsolète depuis longtemps, les gens utilisent encore SSL comme nom pour désigner le trafic réseau chiffré
    Ce serait beaucoup plus simple d’appeler tout trafic réseau chiffré moderne TLS, et de ne dire SSL que lorsqu’on utilise réellement SSL à cause de vrais systèmes legacy

• Je viens de réaliser que mon cerveau avait inconsciemment du mal à distinguer SSL et TLS
  Ce n’est qu’au bout de 20 ans que je comprends pourquoi

  • Pareil pour moi
    Il m’a fallu 15 ans dans ce secteur pour vraiment comprendre que ssl et tls désignaient en gros la même chose, et je me sens idiot
  • Je l’ai appris vers 2010, mais avant ça je ne le savais pas non plus
    Le déclic a été de constater qu’en Java, même quand on utilise aujourd’hui TLSv1.3, on utilise toujours SSLSocket pour démarrer une connexion chiffrée

• « Transport Layer Security » est quand même un meilleur nom
  Dire « TLS » est aussi agréable, alors que SSL, avec deux S à la suite, sonne comme un serpent

  • Le problème, c’est que TLS était déjà largement utilisé comme sigle de thread local storage
    Transport Layer Security est largement documenté comme ayant commencé en 1999, tandis qu’on trouve des références à « Thread Local Storage » remontant au moins à 1996
    À l’époque, le terme était plus courant côté Microsoft, peut-être aussi côté IBM/OS/2, tandis que Pthreads et le monde Unix en général avaient plutôt tendance à parler de « thread-specific data »
    Le document de l’ABI Itanium de 2001 a peut-être diffusé ce terme dans le monde Unix au sens large, mais Sun semble aussi l’avoir utilisé auparavant côté Solaris et Java
  • Au contraire, je trouve que SSL est un nom plus approprié
    En théorie, TLS pourrait être un mécanisme de sécurité de couche transport sur lequel on peut poser n’importe quel protocole, comme IPSec, mais en pratique il est presque toujours lié aux sockets TCP
    DTLS, sa variante UDP, ou QUIC ne font pas non plus partie de la spécification TLS, et même s’il existe le TLS noyau de Linux ou une infrastructure similaire sous Windows, ce n’est pas aussi simple que d’activer TLS avec un simple flag de socket
  • « SSL » est plus facile à prononcer que « TLS », car la position de la langue change à peine entre les trois lettres
  • Le meilleur nom, c’est celui qui est apparu en premier et s’est imposé

• Je me demande ce que les gens disent généralement quand ils expliquent à quelqu’un qu’il faut se connecter à un site web de façon sécurisée, ou dans un contexte où l’on pourrait employer le terme TLS/SSL

  1. Est-ce qu’ils disent SSL ou TLS ?
  2. Quel âge ont-ils, ou travaillaient-ils déjà avant 1999 ?
  • En général, je dis SSL
    Pendant longtemps, je ne savais même pas que TLS était « la même chose », et même maintenant que je le sais, 9 fois sur 10 je dis encore SSL
    J’ai 38 ans et j’ai commencé à travailler en 2011, mais j’ai fait mes premiers pas en programmation réseau vers 2004-2005
    Je viens de regarder un autre écran, et une fonction à laquelle j’ai ajouté une instruction if il y a quelques minutes s’appelait aussi sslCertNotBefore
    Le fait que les programmeurs ne manipulent généralement pas TLS directement fait aussi partie du problème, je pense
    J’ai construit un système qui extrait des informations détaillées de certificat à partir de connexions HTTPS, et récupérer les informations nécessaires dans la bibliothèque standard Java a été assez pénible
    Quand tout est géré automatiquement de façon invisible, il est difficile de se tromper, mais cette mise en boîte noire n’aide pas vraiment à diffuser une compréhension approfondie du fonctionnement réel de TLS
  • Si la plupart des gens disent SSL, c’est sans doute parce que les bibliothèques qui gèrent les communications sécurisées ont SSL dans leur nom
    Il y a notamment OpenSSL, de loin la plus dominante, ainsi que BoringSSL, LibreSSL, wolfSSL, etc.
    Parmi les bibliothèques qui ont TLS dans leur nom, on trouve GnuTLS, mbedTLS, s2n-tls et RustTLS, mais elles sont relativement moins utilisées
  • En général, je dis SSL
    C’est plus susceptible d’être compris que TLS, qui est plus exact, et plus personne n’utilise réellement SSL 3.0 aujourd’hui
    SSL figure aussi dans le nom de bibliothèques classiques comme OpenSSL
    Cela dit, c’est peut-être aussi une habitude qui date de l’époque où j’ai appris SSL, pendant les guerres de la cryptographie des années 1990, quand il fallait se procurer une version « US only » de Netscape pour avoir un vrai chiffrement SSL
  • En général, je dis « https »
    Parce que même le grand public sait parfois ce que cela signifie
  • Ces temps-ci, je dis de plus en plus « TLS », mais il y a encore seulement un ou deux ans, je disais presque toujours « SSL »
    Malgré tout, SSL m’échappe encore parfois
    J’ai 51 ans et j’ai commencé à travailler dans l’IT au milieu des années 90

• Il me semble que TLS 1.0 apportait des améliorations assez importantes par rapport à SSL 3.0
  À lire l’article, on dirait qu’ils ont seulement modifié quelques points pour avoir l’air différent

  • La principale différence concerne le padding
    Quand il a été annoncé à l’avance que l’attaque POODLE ne touchait que SSL3 et pas TLS1.0, cette seule information permettait déjà de prédire qu’il s’agirait d’un oracle de padding
    Les deux sont assez similaires, et il est juste de dire qu’il y avait quelques « corrections de bugs »
    C’était il y a longtemps, donc j’ai peut-être oublié certaines choses, et comme SSL3 et TLS1.0 étaient toujours implémentés ensemble, j’ai peut-être manqué des détails
  • Les changements étaient faibles, plus faibles que dans n’importe quelle autre révision de version
    Dans l’ensemble, c’était surtout l’IETF qui refusait d’approuver tel quel le protocole SSL 3.0 et qui marquait son territoire
  • Il y a bien eu des changements et des améliorations significatifs, mais ce n’était pas une refonte complète comme SSL 3.0

• Il y a aussi, sur un sujet lié, l’article « Randomness and the Netscape Browser » paru dans Dr. Dobb's Journal en janvier 1996
  https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.ht...
  C’est un article écrit en 1996, et la langue employée semble déjà assez différente de celle des publications actuelles, ce qui donne un petit coup de vieux

  • Ça dépend des publications que l’on lit
    Comme c’était déjà le cas en 1996, des articles de LWN aujourd’hui [1] se lisent dans un style assez similaire
    Ils sont peut-être simplement un peu moins austères, car destinés à un lectorat un peu plus généraliste
    [1] https://lwn.net/
  • Les auteurs de cet article ont découvert ce problème de sécurité et ont même fait la une du New York Times : https://www.nytimes.com/2012/02/15/technology/researchers-fi...

• Je me souviens que « SSL and TLS: Designing and Building Secure Systems » d’Eric Rescorla m’avait été vraiment utile pour comprendre l’histoire de TLS et le chemin parcouru jusqu’à aujourd’hui
  C’est un livre paru en 2001, qui signalait déjà plusieurs problèmes devenus ensuite des CVE, et on peut aussi le trouver d’occasion pour quelques dollars

• Vers 2014, je pense que le consensus selon lequel SSL 2.0 était gravement défectueux était déjà très solide
  Même le handshake n’était pas correctement authentifié