Varonis debuts trailblazing features for securing Salesforce. Learn More

Introduction de l'automatisation du moindre privilège pour Microsoft 365, Google Drive et Box

En savoir plus

TLS et SSL : fonctionnement et différences

Les protocoles TLS et SSL permettent de chiffrer les communications privées sur le Web et au-delà. Développé par Netscape, SSL est le protocole le plus ancien. TLS est quant à lui un protocole ouvert, basé sur SSL.
Robert Grimmick
7 minute de lecture
Publié 11 octobre 2021
Dernière mise à jour 29 juin 2022

Est-ce un oiseau ? Est-ce un avion ? Non, c’est un protocole de chiffrement des réseaux ! Certes, contrairement à Superman, ils ne viennent pas de la planète Krypton, mais les protocoles Transport Layer Security (TLS) et Secure Sockets Layer (SSL) assurent pourtant un rôle surhumain : protéger nos communications personnelles face aux malandrins les plus déterminés. Tout comme les habitants de Metropolis semblent souffrir d’un aveuglement sélectif les empêchant de comprendre que Clark Kent n’est autre que leur extra-terrestre volant préféré, le monde des technologies a longtemps opposé TLS et SSL, parfois avec un pédantisme appuyé, refusant d’admettre que ces protocoles sont en réalité très similaires.

Dans cet article, nous allons clarifier ces deux dénominations, nous pencher sur les causes historiques de cette opposition entre SSL et TLS, et découvrir comment ces deux technologies assurent notre protection en ligne, même lorsque nous utilisons des réseaux partagés, par exemple via un point d’accès Wi-Fi.

Définitions importantes à connaître

Toute discussion sur la sécurité Web peut rapidement se transformer en un gloubi-boulga impénétrable d’acronymes et de termes spécialisés. Pour bien comprendre de quoi nous parlons, il convient néanmoins de clarifier les termes ci-dessous.

Qu’est-ce que le protocole TLS ?

TLS est le protocole le plus utilisé pour sécuriser les communications entre appareils sur un réseau. Son objectif ? Assurer la confidentialité et l’intégrité des informations transmises, même lorsque les liens réseau eux-mêmes ne sont pas parfaitement fiables. Le plus souvent, TLS permet de sécuriser des sessions entre un navigateur et un serveur Web, mais il peut très bien être utilisé pour les VPN ou encore les chats vidéo.

La version 1.0 du protocole TLS a fait son apparition en 1999. Elle était alors très largement basée sur le protocole SSL, développé quelques années auparavant par Netscape. Si cette nouvelle version porte un nom distinct, c’est pour bien clarifier le fait qu’il s’agissait d’une norme ouverte que l’ensemble des entreprises et projets pouvaient utiliser. À l’époque, Netscape utilisait en effet SSL dans son logiciel propriétaire pour serveurs Web (Netscape Enterprise Server) afin de chiffrer les données en transit. Ce protocole ouvert a par la suite été mis à jour à plusieurs reprises. La dernière version disponible, TLS 1.3, date de 2018.

Qu’est-ce que SSL ?

SSL est la première technologie utilisée à grande échelle pour sécuriser les communications sur le Web. Développé au milieu des années 90 par une équipe de Netscape dont faisait notamment partie Taher Elgamal, un cryptographe de renom, ce protocole a posé les bases de notre Internet actuel. Ses versions initiales présentaient des faiblesses majeures, mais une fois sa version 3.0 atteinte, il a permis d’accompagner le boom de l’e-commerce et d’autres activités en ligne inimaginables sans chiffrement.

Algorithmes, certificats et HTTPS

TLS a été conçu pour accomplir une tâche surhumaine : protéger nos communications et transactions des hackers les plus doués. Pour y parvenir, le protocole s’appuie sur une série de technologies complexes, dont certaines sont ajoutées ou retirées lorsque des vulnérabilités font leur apparition. Voici quelques-unes des plus importantes d’entre elles :

Les algorithmes cryptographiques convertissent les informations en clair en texte chiffré que seules les parties autorisées peuvent visualiser. SSL et TLS utilisent une combinaison d’algorithmes appelée « suite cryptographique » pour protéger le contenu, l’intégrité et l’authenticité des messages. Les fonctions mathématiques de chaque algorithme sont évaluées en permanence pour permettre la détection d’éventuelles vulnérabilités. Lorsque de telles vulnérabilités sont détectées, de nouveaux algorithmes sont mis en place, ce qui s’est produit à plusieurs reprises au fil des années.

Autre maillon clé des protocoles TLS et SSL, les certificats. Leur objectif est double : valider l’identité du site auquel un utilisateur essaie de se connecter et fournir la clé de chiffrement publique permettant de décoder les messages chiffrés envoyés par le site.

Hypertext Transfer Protocol Secure (HTTPS) n’est ni plus ni moins que la version sécurisée du protocole Hypertext Transfer Protocol (HTTP), utilisé par les navigateurs et les serveurs Web pour communiquer entre eux. TLS et SSL ne modifient pas le fonctionnement sous-jacent de ce protocole, mais encapsulent les messages HTTP classiques dans une couche de chiffrement. HTTPS correspond ainsi davantage à la combinaison de HTTP avec TLS ou SSL qu’à la dénomination d’un nouveau protocole à proprement parler.

L’histoire de TLS et SSL

De nombreuses normes et de nombreux protocoles utilisés aujourd’hui sur Internet ont été élaborés à une époque où la sécurité informatique n’avait que peu d’importance. Cet état d’esprit explique pourquoi le protocole IP de la couche réseau et le protocole HTTP qui sert de socle au Web n’intègrent ni chiffrement ni authentification. Ce manque de sécurité a une conséquence directe : n’importe quelle personne placée entre vous et un serveur Web peut écouter, voire manipuler le trafic. Ce n’était pas un vrai problème lorsque notre activité la plus sensible consistait à se balader sur Lycos et à s’échanger des œuvres d’art ASCII sur le thème de Star Trek. En revanche, nos activités modernes, que ce soit la gestion de nos comptes bancaires ou la prise de rendez-vous médicaux, imposent une sécurité renforcée.

À la fin des années 80 et au début des années 90, les experts et chercheurs informatiques issus du monde académique, des agences gouvernementales et des entreprises, ont cherché où et comment mettre en place un chiffrement tout en préservant la compatibilité avec l’infrastructure réseau et les applications déjà utilisées dans le monde entier. Ils ont réfléchi à plusieurs solutions et protocoles, mais aucun de leurs premiers essais n’a réellement pris. En revanche, de nombreux concepts d’ordre général imaginés à l’époque ont par la suite été repris dans SSL, puis TLS.

  • 1986-1995 : divers groupes se penchent sur la question de la protection des informations confidentielles en transit sur le réseau. Plusieurs techniques sont proposées, mais la majorité du trafic Internet est encore échangé en clair.
  • 1995 : Netscape introduit Secure Sockets Layer (SSL) pour sécuriser le trafic Web.
  • 1999 : Transport Layer Security (TLS) 1.0, basé sur SSL, devient une norme ouverte et le choix par défaut pour sécuriser les sites d’e-commerce et le trafic important.
  • 2008 : TLS 1.2 fait son apparition. Au programme de cette nouvelle version, une sécurité renforcée, de nouvelles suites cryptographiques et la possibilité de déterminer l’ordre d’utilisation des algorithmes de sécurité.
  • 2012-2017 : les inquiétudes concernant la surveillance et l’écoute du trafic se font de plus en plus fortes. Des voix s’élèvent pour demander le chiffrement de l’ensemble du trafic Web. En 2017, Google commence à inclure l’utilisation du chiffrement SSL/TLS dans ses critères de classement.
  • 2018 : la version 1.3 de TLS est dévoilée. Elle renforce encore plus la confidentialité du trafic. Certains gouvernements et entreprises critiquent cette nouvelle version, jugeant qu’elle va trop loin.

Aujourd’hui : TLS 1.2 est la version minimale acceptable en production.

Différences clés entre TLS et SSL

Bien que la distinction dans leur nom puisse laisser penser le contraire, il n’y a jamais réellement eu de débat « TLS contre SSL ». La théorie sous-jacente à chacun de ces protocoles est très proche, et TLS n’est qu’une évolution naturelle de SSL. La véritable différence entre eux réside en réalité dans leurs auteurs. SSL a été créé par Netscape et constituait à l’origine un produit propriétaire, tandis que TLS a toujours été une norme ouverte élaborée par l’Internet Engineering Task Force (IETF) depuis sa version 1.0.

Techniquement, chaque itération de TLS depuis sa version 1.0 jusqu’à sa version 1.3 a corrigé des vulnérabilités de la version immédiatement antérieure, ce qui signifie que TLS 1.3 est bien plus sécurisé que la dernière version de SSL. Parmi les autres modifications, on peut évoquer des améliorations des performances et le retrait de suites cryptographiques dont la sécurité est considérée comme obsolète.

Certificats TLS et SSL

Vous connaissez peut-être déjà les certificats SSL. Les certificats numériques jouent un rôle tout aussi important avec TLS qu’avec SSL. Simplement, lorsque TLS a fait son apparition, nous avions déjà pris l’habitude de parler de « certificat SSL » et l’expression est restée, alors qu’il existe bel et bien des « certificats TLS ». Comme si la confusion entre certificats TLS et SSL ne suffisait pas, les deux protocoles reposent techniquement sur des certificats X.509, même si ce point n’est presque jamais mentionné.

Quel que soit le nom que vous leur donnez, les certificats fonctionnent tous de la même façon et jouent plusieurs rôles essentiels dans l’architecture de sécurité. Tout d’abord, ils authentifient l’identité de leur détenteur. Lorsque vous vous connectez sur varonis.com, vous avez la certitude d’être sur le site de Varonis, car le serveur a présenté à votre navigateur un certificat. Pour confirmer cette opération, votre navigateur affiche une icône de cadenas dans la barre d’adresse. Vous pouvez consulter le certificat en cliquant sur cette icône :

Les certificats sont émis par une organisation appelée autorité de certification (CA). Dans cet exemple, le certificat de Varonis a été émis par GlobalSign. Les navigateurs sont dotés d’une liste pré-installée d’autorités de confiance, qui disposent elles-mêmes d’un certificat numérique signé par une autorité racine. Les certificats peuvent aussi être auto-signés, mais votre navigateur générera alors une alerte. Cette stratégie ne doit jamais être utilisée en production, car l’auto-signature ne permet pas de garantir l’authenticité du certificat.

En plus de l’authentification, les certificats permettent d’utiliser de manière très astucieuse ce qu’on appelle le chiffrement asymétrique, avec SSL comme avec TLS. Le chiffrement asymétrique tire son nom de l’utilisation de deux clés distinctes pour le chiffrement et le déchiffrement des données. Habituellement, une de ces clés est secrète, tandis que l’autre peut être partagée librement. Ce modèle s’oppose à celui du chiffrement symétrique, dans lequel une seule clé permet le chiffrement et le déchiffrement. Le chiffrement symétrique demande beaucoup moins de ressources que sa version asymétrique, mais impose de maintenir la clé secrète pour assurer la confidentialité du message. Cette particularité pose un problème lorsque ces clés doivent être envoyées par le biais d’un support non sécurisé ou non fiable, Internet par exemple. Les développeurs de SSL/TLS ont eu une idée pour réunir le meilleur des deux mondes : le chiffrement asymétrique permettrait l’échange d’une clé symétrique unique à chaque session de navigation.

Pendant la conversation initiale, nommée « handshake », le client et le serveur décident de la suite cryptographique à utiliser, puis génèrent une clé symétrique unique à l’aide de l’un des algorithmes de chiffrement asymétriques. Cette clé sera utilisée pour le restant de la session. Le recours au chiffrement asymétrique pendant le handshake empêche de capturer ou de deviner facilement la clé de la session, même si le hacker écoute le lien réseau. Bien entendu, le processus est techniquement un peu plus complexe que ces quelques lignes le laissent entendre, mais les concepts généraux n’ont pas changé depuis l’avènement du SSL.

Dois-je utiliser TLS ou SSL ?

Toutes les versions de SSL sont désormais considérées comme obsolètes et ne doivent donc plus être utilisées. Les navigateurs modernes considèrent les connexions SSL ou même les connexions réalisées avec une ancienne version de TLS, comme non sécurisées, car ces protocoles renferment de nombreuses vulnérabilités connues. Toutefois, la terminologie est utilisée de manière très fluctuante, et le terme « SSL » est très souvent employé en tant que synonyme de « système de sécurisation des communications Web ». Il est par exemple très courant de parler de « certificat SSL » en référence aux certificats utilisés pour la cryptographie asymétrique, même lorsque ces certificats sont en réalité utilisés avec les versions les plus récentes de TLS.

Ces imprécisions mises à part, il est important de désactiver la prise en charge de l’ensemble des versions de SSL sur votre serveur Web et vos autres applications. Si vous ne le faites pas, vous entrerez en violation avec de nombreuses normes de sécurité, notamment PCI DSS. Au-delà des questions de conformité, SSL et les premières versions de TLS renferment des vulnérabilités suffisamment graves pour ne plus assurer réellement la protection des communications.

Ces protocoles ne suffisent pas…

TLS, et SSL avant lui, contribuent grandement à la sécurisation de nos communications, mais ils ne sont pas parfaits pour autant. Ces petits cadenas dans la barre d’adresse de votre navigateur ne permettent que de garantir que la connexion est sécurisée : vous ne pouvez rien en déduire du contenu transmis via cette connexion. Des malwares sont régulièrement transmis via TLS/SSL, et l’utilisation du chiffrement peut même complexifier la tâche des solutions de sécurité. Par ailleurs, les protocoles TLS et SSL concernent uniquement les données en transit et ne sécurisent absolument pas les données au repos.

Comme toujours, il est préférable de s’intéresser à la sécurité depuis différents points de vue. L’utilisation de TLS pour chiffrer les données confidentielles est une bonne chose, mais les entreprises doivent également prendre des mesures pour réduire leur risque global et suivre les bonnes pratiques, comme la mise à jour des systèmes d’exploitation et l’utilisation d’un logiciel de sécurité des terminaux.

What you should do now

Below are three ways we can help you begin your journey to reducing data risk at your company:

  1. Schedule a demo session with us, where we can show you around, answer your questions, and help you see if Varonis is right for you.
  2. Download our free report and learn the risks associated with SaaS data exposure.
  3. Share this blog post with someone you know who'd enjoy reading it. Share it with them via email, LinkedIn, Reddit, or Facebook.
Testez Varonis gratuitement.
Un résumé détaillé des risques liés à la sécurité de vos données.
Stratégie claire vers une remédiation automatisée.
Déploiement rapide.
Keep reading
guide-de-l’acheteur-de-dspm
Guide de l’acheteur de DSPM
Comprenez les différents types de solutions DSPM, évitez les pièges les plus courants et posez les bonnes questions pour vous assurer que vous achetez une solution de sécurité des données qui répond à vos besoins spécifiques.
derrière-la-refonte-de-la-marque-varonis
Derrière la refonte de la marque Varonis
Découvrez la stratégie derrière la refonte de Varonis qui impliquait une transition complète vers un archétype de héros et l'introduction de Protector 22814.
tendances-en-matière-de-cybersécurité-pour 2024 :-ce-que-vous-devez-savoir
Tendances en matière de cybersécurité pour 2024 : ce que vous devez savoir
Apprenez-en davantage sur la gestion de la posture en matière de sécurité des données, les risques liés à la sécurité de l’IA, les changements en termes de conformité et bien plus encore pour préparer votre stratégie en matière de cybersécurité pour 2024.
trois façons-dont-varonis-vous-aide-à-lutter-contre-les-menaces-internes
Trois façons dont Varonis vous aide à lutter contre les menaces internes
Les entreprises ont du mal à lutter contre les menaces internes. Pour lutter contre elles, Varonis s’appuie sur la « triade de la sécurité des données » (sensibilité, accès et activité).