Différentes implémentations SSL/TLS : historique, variantes et points forts

En matière de sécurité des communications internet, les deux acronymes les plus fréquemment mentionnés sont SSL et TLS . Ils sont devenus si courants qu'ils apparaissent même dans les navigateurs sous la forme d'un petit cadenas à côté de l'adresse web, symbole désormais universel d'une connexion sécurisée. Mais que sont-ils exactement ? Et surtout, quels mécanismes sont mis en œuvre en coulisses pour garantir la confidentialité de nos données ?

Pour comprendre cela, il est utile de revenir un peu en arrière. Le protocole SSL (Secure Sockets Layer) a été développé dans les années 90 par Netscape, dans le but de créer un canal chiffré entre le client et le serveur afin de protéger les mots de passe, les numéros de carte bancaire et toute information privée échangée en ligne. Les premières versions de SSL étaient novatrices, mais non sans failles, à tel point qu'à la fin des années 90, il a été décidé d'adopter une norme plus robuste appelée TLS (Transport Layer Security) . TLS peut être considéré comme le successeur naturel de SSL, à tel point qu'aujourd'hui, lorsque l'on parle de « SSL », on fait presque toujours référence à TLS, même si les protocoles SSL originaux sont depuis longtemps considérés comme non sécurisés et obsolètes.

TLS repose sur un ensemble de primitives cryptographiques : algorithmes de chiffrement, fonctions de hachage, courbes elliptiques (RSA) pour l'échange de clés et protocoles de négociation pour une session sécurisée. C'est une couche située au-dessus de TCP et en dessous des applications : qu'il s'agisse de HTTPS, d'IMAPS ou de SMTP avec STARTTLS, tout fonctionne selon le même principe : établir un canal chiffré et authentifié entre deux points de communication.

Voilà pour la théorie. Mais comment cela fonctionne-t-il en pratique ? Qui met tout cela en œuvre ? C’est là qu’interviennent les bibliothèques logicielles qui implémentent TLS, à savoir les moteurs cryptographiques utilisés par les serveurs web, les systèmes d’exploitation, les navigateurs et les systèmes embarqués. Le paysage est diversifié et reflète différents besoins : performance, portabilité, sécurité, facilité d’utilisation et compatibilité avec les réglementations locales. Certaines bibliothèques sont nées de projets dérivés, d’autres comme des alternatives radicales, et d’autres encore en réponse à des failles de sécurité retentissantes qui ont ébranlé la confiance dans les normes.

Dans cet article, nous explorerons les implémentations les plus importantes : OpenSSL , la bibliothèque de référence, et ses dérivés les plus connus comme LibreSSL , BoringSSL et BabaSSL . Nous examinerons ensuite des solutions développées indépendamment, telles que WolfSSL , conçue pour l’Internet des objets (IoT), GnuTLS , une expression de l’univers GNU, et NSS , la bibliothèque historique de Mozilla. Chacune de ces bibliothèques possède son histoire, son contexte d’utilisation et ses atouts, qui la rendent adaptée à certains scénarios.

Comment fonctionne SSL en théorie, en termes généraux ?

Imaginez devoir parler à un ami dans une pièce remplie de personnes curieuses. Vous ne voulez pas que quiconque comprenne ce que vous dites, vous avez donc besoin d'un moyen de chiffrer vos messages . Cependant, vous ne pouvez pas simplement dire votre « mot secret » à voix haute, car quelqu'un pourrait l'entendre et l'utiliser contre vous. Vous mettez donc au point une méthode : vous échangez d'abord quelques phrases codées qui vous permettent à tous les deux d'arriver, sans que personne d'autre ne s'en aperçoive, à une clé commune connue de vous seuls. Une fois cette clé trouvée, vous pouvez parler librement : quiconque vous écoute n'entendra qu'une série de sons incompréhensibles.

C’est précisément ce que fait SSL/TLS : il établit un canal sécurisé entre deux parties (généralement un navigateur et un serveur web) grâce à un processus de négociation initial appelé poignée de main , puis protège l’échange de données par chiffrement et contrôles d’intégrité.

La poignée de main TLS expliquée étape par étape

En coulisses, le protocole suit une séquence bien définie. On peut le résumer en grandes phases :

1. ClientHello : Le client (par exemple, le navigateur) envoie un message au serveur contenant la liste des versions TLS qu'il prend en charge, les suites de chiffrement disponibles (ensembles d'algorithmes) et un nombre aléatoire (nonce) qui sera utilisé dans la génération de clés.

2. ServerHello : Le serveur répond en choisissant une version TLS et une suite de chiffrement compatibles avec celles proposées par le client. Il envoie ensuite un nonce et, surtout, le certificat numérique X.509 attestant de son identité.

3. Vérification du certificat : Le client vérifie que le certificat est valide, signé par une autorité de certification reconnue et non révoqué. Cette étape nous confirme : « Oui, je communique bien avec example.com et non avec un imposteur. »

4. Échange de clés : C’est là qu’intervient la cryptographie asymétrique. À l’aide de RSA, ECDHE ou d’autres algorithmes, clients et serveurs collaborent pour générer une clé de session symétrique . Point important : cette clé n’est jamais transmise en clair ; elle est calculée mathématiquement à partir des nonces échangés et des paramètres cryptographiques.

5. Confirmation : Une fois la clé obtenue, le client et le serveur s'envoient des messages chiffrés pour prouver qu'ils possèdent la même clé.

6. Session sécurisée : Désormais, toutes les données transitent chiffrées à l'aide d'algorithmes symétriques (par exemple AES ou ChaCha20), qui sont beaucoup plus rapides à calculer.

Les piliers théoriques : confidentialité, intégrité, authenticité

SSL/TLS n’est pas seulement un protocole de cryptage, mais un ensemble de mesures de protection.

• Confidentialité : Grâce au chiffrement symétrique, seules les deux parties communicantes peuvent lire les données.

• Intégrité : Chaque message est accompagné d'un code (MAC ou HMAC, selon la version) qui nous permet de détecter s'il a été modifié.

• Authenticité : Les certificats numériques permettent d'être raisonnablement sûr de l'identité du serveur (et parfois du client).

Du simple au technique : symétrique et asymétrique

L'un des aspects clés est la combinaison de la cryptographie asymétrique et symétrique.

• La cryptographie asymétrique (RSA, Diffie-Hellman, courbes elliptiques) a été initialement utilisée car elle permettait à deux parties d'établir une clé commune sans avoir à la transmettre en clair. Elle est très sûre, mais aussi lente.

• Une fois la clé de session établie, le chiffrement symétrique prend le relais : les deux parties utilisent la même clé pour chiffrer et déchiffrer les données. Ce système est beaucoup plus rapide, ce qui le rend idéal pour gérer un trafic important.

Cet équilibre entre les deux types de cryptage est ce qui rend TLS à la fois sécurisé et efficace.

Versions et évolution de TLS

Au fil du temps, le protocole a connu plusieurs mises à jour. SSL 2.0 et SSL 3.0 sont actuellement considérés comme non sécurisés. Les versions TLS ont progressivement amélioré la sécurité :

• Les versions 1.0 et 1.1 de TLS sont désormais obsolètes.

• TLS 1.2 reste très répandu, stable et considéré comme sûr.

• TLS 1.3 , la dernière version, a considérablement simplifié l'établissement de la connexion, éliminé les algorithmes vulnérables et amélioré la vitesse. L'établissement d'une session sécurisée nécessite désormais moins d'échanges de messages, ce qui réduit la latence.

Un aperçu

En conclusion, en théorie, le protocole SSL/TLS s'apparente à un rituel de présentation et d'accord entre deux interlocuteurs : ils se reconnaissent d'abord, puis décident ensemble de leur mode de communication, et enfin échangent des messages de manière sécurisée, à l'abri des regards indiscrets. En pratique, cela est rendu possible grâce à des mécanismes de chiffrement sophistiqués, des certificats numériques et des codes d'intégrité, qui fonctionnent de manière transparente pour l'utilisateur.

La magie du protocole réside précisément dans cela : derrière un simple cadenas vert dans le navigateur se cache un système complexe, fait de mathématiques et de normes partagées, qui permet chaque jour à des milliards de personnes de naviguer, d’acheter, d’échanger des messages et de travailler en ligne avec un niveau de sécurité qui, il y a quelques décennies encore, aurait été impensable.

OpenSSL : la pierre angulaire du chiffrement open source

Impossible de parler de SSL/TLS sans évoquer OpenSSL , la bibliothèque la plus populaire et la plus ancienne. Née à la fin des années 90 comme une évolution de SSLeay, elle est devenue la norme de facto pour l'ensemble du monde open source et bien au-delà. Apache HTTP Server, Nginx, Postfix, MySQL : pratiquement tous les logiciels nécessitant des communications chiffrées utilisent ou ont utilisé OpenSSL.

Sa principale force a toujours résidé dans son exhaustivité . OpenSSL fournit non seulement l'implémentation du protocole TLS, mais aussi une vaste collection de primitives cryptographiques : RSA, DSA, DH, courbes elliptiques, AES, ChaCha20, SHA, HMAC, algorithmes de chiffrement classiques, et bien d'autres. Véritable couteau suisse, il va bien au-delà de TLS et permet de générer des certificats X.509, de gérer des infrastructures à clés publiques (PKI), de vérifier des signatures numériques, de créer des VPN ou des systèmes de chiffrement de fichiers.

Son utilisation généralisée s'explique aussi par sa licence de type Apache , qui a favorisé son intégration dans les logiciels libres et les solutions propriétaires. Cependant, cette même omniprésence a rendu son rôle crucial cruellement évident lors de l'explosion de la vulnérabilité Heartbleed en 2014 , une faille dans l'implémentation de l'extension TLS Heartbeat permettant la lecture de la mémoire du serveur. Heartbleed a ébranlé le monde informatique, révélant qu'une infrastructure aussi essentielle était maintenue par un nombre très restreint de développeurs, avec des financements limités et un code dont la maintenance n'était pas toujours aisée.

Depuis, le projet a connu une phase de revitalisation, avec un financement accru, des audits de sécurité et des versions plus régulières. Aujourd'hui, OpenSSL reste la bibliothèque de référence en matière de compatibilité et de support, mais cette crise a ouvert la voie à divers forks cherchant à proposer des alternatives plus sûres ou plus légères.

LibreSSL : la réponse d'OpenBSD à Heartbleed

LibreSSL est né en réaction à Heartbleed , au sein d'une branche de l'équipe OpenBSD. La philosophie de ce projet était claire : faire le ménage. OpenSSL s'était développé de manière chaotique, avec beaucoup de code hérité, des API jugées non sécurisées et des problèmes de compatibilité persistants pour des systèmes obsolètes. Les développeurs d'OpenBSD ont donc décidé d'éliminer les fonctionnalités superflues, de simplifier l'API et de se concentrer sur la sécurité et la lisibilité.

LibreSSL se distingue par la rigueur de son code . L'approche d'OpenBSD a toujours été reconnue pour sa culture du « sécurité par défaut », et c'est ce même esprit qui inspire cette bibliothèque. Ce n'est pas un hasard si de nombreuses parties du code ont été réécrites, mises aux normes C modernes et débarrassées des fonctions dangereuses, notamment celles qui ne vérifient pas correctement les tampons.

La principale limitation de LibreSSL réside dans sa compatibilité . Plus minimaliste, il ne peut pas toujours prendre en charge toutes les API requises par les logiciels qui s'attendent à utiliser les fonctionnalités d'OpenSSL. Cela a freiné sa diffusion en dehors de l'univers *BSD et de certaines distributions Linux. Il demeure néanmoins une référence pour ceux qui recherchent une implémentation simple, axée sur la sécurité du code plutôt que sur une compatibilité absolue.

BoringSSL : l'implémentation de Google pour Chrome et Android

BoringSSL , maintenu par Google, est une autre version dérivée née de besoins spécifiques . Dans ce cas précis, le problème n'était pas tant Heartbleed que la nécessité d'un code SSL/TLS adapté aux vastes plateformes de Google, telles que Chrome, Android, gRPC et les services cloud.

BoringSSL n'a jamais eu l'ambition de devenir une bibliothèque universelle comme OpenSSL. Au contraire, Google l'a toujours présenté comme un projet interne, optimisé pour ses propres besoins et non recommandé pour un usage général. L'objectif était de réduire la complexité, d'éliminer les fonctionnalités obsolètes et d'accélérer le cycle de développement, en phase avec le rythme des correctifs de sécurité nécessaires pour protéger des milliards d'utilisateurs.

Ses atouts résident donc dans sa rapidité de développement , son approche axée sur la sécurité de la mémoire (bien qu'il soit toujours écrit en C, de nombreuses mesures d'atténuation ont été mises en place) et son intégration à l'écosystème Google. BoringSSL fournit également des bibliothèques secondaires telles qu'AWS-LC , la version dérivée maintenue par Amazon Web Services.

Sa principale limite, encore une fois, réside dans la compatibilité . BoringSSL n'expose pas toutes les API d'OpenSSL et n'a pas vocation à le remplacer de manière transparente. C'est pourquoi il n'est jamais devenu un choix standard pour les développeurs tiers, mais il a joué un rôle déterminant en démontrant que des bibliothèques plus légères sont possibles et même souhaitables dans certains contextes.

WolfSSL : le choix idéal pour l'IoT et les systèmes embarqués

Si OpenSSL est le géant généraliste, WolfSSL représente la spécialité. Initialement connue sous le nom de CyaSSL, puis renommée, cette bibliothèque est spécifiquement conçue pour les systèmes embarqués et l'Internet des objets. Les microcontrôleurs, routeurs et dispositifs industriels ou médicaux disposent de ressources limitées : mémoire restreinte, processeurs peu puissants et exigences de latence strictes. Dans ces contextes, une bibliothèque aussi volumineuse qu'OpenSSL s'avère souvent inadaptée.

WolfSSL est écrit en C portable, avec une conception particulièrement légère . La taille du binaire est réduite, les modules sont configurables selon les besoins et des optimisations matérielles permettent de réduire la consommation d'énergie. Ce n'est pas un hasard s'il prend en charge un large éventail d'architectures et d'environnements RTOS.

Un autre atout majeur est la certification . WolfSSL a été validé selon diverses normes telles que FIPS 140-2 et DO-178C pour les applications avioniques, ce qui le rend attractif pour les secteurs où la conformité est essentielle. C'est pourquoi il est prisé des fabricants de systèmes embarqués qui doivent garantir non seulement la sécurité technique, mais aussi la conformité réglementaire.

Sa limite réside toutefois dans le fait qu'il n'offre pas toujours les mêmes extensions d'algorithmes ou API héritées que celles d'OpenSSL. Il est conçu pour ceux qui recherchent efficacité et portabilité, plutôt que pour ceux qui souhaitent maintenir une compatibilité universelle.

GnuTLS : l'alternative mondiale à GNU

L'univers du logiciel libre ne pouvait se passer d'une solution estampillée GNU : GnuTLS . Cette bibliothèque a été créée dans le but de fournir une implémentation TLS compatible avec les directives du projet GNU et de la Free Software Foundation. À l'époque, OpenSSL possédait une licence jugée non entièrement compatible avec la GPL, et GnuTLS se voulait la solution entièrement libre.

Son principal atout réside dans son intégration à l'écosystème GNU/Linux . De nombreux logiciels basés sur GNU ont opté pour GnuTLS précisément pour des raisons de licence et de cohérence philosophique. Au fil du temps, le projet s'est également distingué par certaines caractéristiques techniques, telles que l'adoption précoce de protocoles modernes et une forte orientation vers la configurabilité.

Comparé à OpenSSL, GnuTLS a souvent été moins populaire dans le monde de l'entreprise, mais il joue un rôle crucial dans l'écosystème du logiciel libre. Il est largement utilisé par les applications qui souhaitent s'affranchir du mastodonte OpenSSL et adopter une bibliothèque conforme aux principes GNU. Même en termes d'API, il est parfois plus simple et direct, bien que moins universel.

NSS : la bibliothèque historique de Mozilla

Une autre implémentation qui mérite l'attention est NSS (Network Security Services) , initialement développée par Netscape et désormais maintenue par Mozilla et Red Hat. Elle constitue le cœur cryptographique de Firefox depuis des années , mais pas seulement : elle est également utilisée dans des solutions d'entreprise, des systèmes de messagerie et divers produits Red Hat.

NSS se distingue par son approche globale, allant au-delà du protocole TLS : il intègre une infrastructure à clés publiques (PKI) complète , avec gestion des certificats, bibliothèques S/MIME et outils de signature et d’authentification numériques. Conçu comme une pile de sécurité plus large, il privilégie l’intégration avec les navigateurs et les systèmes d’exploitation.

Sa force réside dans sa maturité et sa robustesse . Utilisé dans Firefox et d'autres contextes largement répandus, il a bénéficié d'une attention considérable en matière de sécurité et de correction de bogues. De plus, sa prise en charge étendue de la gestion des certificats le rend adapté aux scénarios d'authentification complexes en entreprise.

L'inconvénient est que, hors du contexte de Mozilla et Red Hat, il a perdu du terrain face à OpenSSL et ses dérivés. Il demeure néanmoins un pilier historique, qui a contribué à l'évolution de la norme TLS dans les navigateurs et continue d'être soigneusement entretenu.

BabaSSL, désormais Tongsuo : la variante chinoise avec des algorithmes nationaux

Une implémentation moins connue en Occident, mais d'une grande importance en Asie, est désormais appelée Tongsuo . Évolution de BabaSSL , il s'agit d'une version dérivée d'OpenSSL développée en Chine avec un objectif précis : intégrer nativement les normes cryptographiques nationales obligatoires, telles que SM2, SM3 et SM4 . Contrairement au reste du monde, où le chiffrement repose principalement sur AES, RSA ou les courbes NIST, la loi chinoise impose l'utilisation d'un ensemble d'algorithmes locaux, et Tongsuo constitue la réponse technique à cette exigence.

Tongsuo est donc le choix idéal pour ceux qui doivent se conformer aux réglementations locales, et c'est pourquoi il est utilisé dans plusieurs produits et services chinois. Outre la prise en charge de NTLS (National TLS) , l'équivalent national du protocole TLS, il est également compatible avec les protocoles internationaux, ce qui le rend adapté aux scénarios mixtes où il est nécessaire de communiquer à la fois avec des clients internationaux et des clients respectant les normes chinoises.

Son principal atout réside donc dans sa conformité réglementaire . Sur un marché aussi vaste que celui de la Chine, disposer d'une bibliothèque implémentant nativement les algorithmes nationaux est essentiel pour garantir l'interopérabilité et le respect des réglementations. Cependant, cette même orientation limite sa diffusion hors de Chine : dans les contextes occidentaux, rares sont ceux qui ont réellement besoin d'utiliser des algorithmes tels que SM2 ou NTLS, ce qui explique pourquoi Tongsuo demeure une bibliothèque très spécialisée et de niche.

Conclusions : laquelle choisir ?

Comme nous l'avons vu, il n'existe pas une seule implémentation TLS, mais tout un écosystème de bibliothèques conçues pour répondre à différents besoins. OpenSSL demeure la plus universelle, garantissant une compatibilité maximale. LibreSSL , bien que moins répandue, est un symbole de rigueur et de clarté du code. BoringSSL illustre l'approche pragmatique de Google, axée sur ses propres services. WolfSSL ouvre la voie à l'Internet des objets (IoT) et aux systèmes embarqués. GnuTLS reste la référence du monde GNU. NSS continue de garantir la sécurité des navigateurs et des solutions d'entreprise. Enfin, BabaSSL représente l'adaptation aux normes nationales chinoises.

Il est clair que la cryptographie et la sécurité ne sont jamais statiques. L'évolution des bibliothèques SSL/TLS reflète à la fois l'histoire d'Internet et la tension constante entre compatibilité, performance, conformité et sécurité. Chaque implémentation raconte une partie de cette histoire, et le choix dépend du contexte : un centre de données mondial, un appareil IoT, un navigateur, un marché national.

En fin de compte, la richesse des alternatives est un signe de vitalité : elle signifie que TLS, le cœur de la sécurité Web, continue d’évoluer et de trouver des réponses ciblées aux défis d’un monde numérique de plus en plus complexe et diversifié.