Qu’est-ce que le protocole TLS (Transport Layer Security) ?

Grâce à diverses techniques de cryptographie asymétrique et symétrique, TLS assure l’authentification, la confidentialité et l’intégrité des données de bout en bout. Ces protections s’appliquent à différents types de communication réseau dont les e-mails, la messagerie, la voix sur IP (VoIP) et les réseaux privés virtuels (VPN).

Le protocole TLS est connu pour sécuriser les connexions lors de la navigation sur Internet. Il sert de base au HTTPS (Hypertext Transfer Protocol Secure), un protocole de la couche applicative qui permet de chiffrer les échanges de données entre les applications Web et les principaux navigateurs Web.

Le protocole de chiffrement TLS comporte deux couches : le protocole de négociation (handshake) TLS et le protocole d’enregistrement TLS. Le protocole de négociation authentifie le serveur Web et le client (le dispositif qui se connecte au serveur). Le protocole d’enregistrement vérifie et sécurise les données à transporter.

Ces couches se situent au-dessus d’un protocole de transport, comme celui du modèle TCP/IP (Transmission Control Protocol/Internet Protocol), une suite de protocoles qui spécifient les normes de communication entre ordinateurs et qui sont considérés comme « le liant qui assure la cohésion de l’Internet ».¹

Le protocole TLS succède au protocole SSL (Secure Sockets Layer) développé par Netscape Communications Corporation. En 1996, l’Internet Engineering Task Force (IETF) a officiellement normalisé le protocole SSL.

En janvier 1999, l’IETF apporte des améliorations et corrige les vulnérabilités de la dernière version de SSL (SSL 3.0), la renommant Transport Layer Security (TLS). Cette version est officiellement définie dans la Request for Comments (RFC) 2246. Aujourd’hui, les termes « TLS » et « SSL » sont souvent utilisés de manière interchangeable ou présentés ensemble sous la forme TLS/SSL.

Considéré par l’IETF comme étant « le protocole de sécurité le plus important sur Internet », TLS joue un rôle essentiel dans la protection des communications en ligne contre les accès non autorisés. Sa dernière version, TLS 1.3, qui offre une sécurité renforcée et plus rapide, est indispensable pour protéger le monde numérique d’aujourd'hui.

Près de 68 % de la population mondiale est connectée à Internet², et des milliards de personnes l’utilisent au quotidien : achats, opérations bancaires, soins de santé et communications personnelles. Dans tous ces cas d’utilisation, la protection des données sensibles est essentielle. Il s’agit de les protéger contre les pirates, la falsification, les écoutes et autres menaces de cybersécurité telles que les violations de données, les logiciels malveillants ou les attaques de type « homme du milieu ».

Le protocole TLS est spécifiquement utilisé pour le protocole HTTPS, le protocole de sécurité standard appliqué aux sites Web. L’icône de cadenas HTTPS, une fonctionnalité désormais connue dans les navigateurs Web, signale aux utilisateurs que le site Web est digne de confiance et sécurisé.

L’icône indique également que le site Web dispose d’un certificat TLS valide (également appelé certificat SSL). Ce certificat numérique, émis par une autorité de certification (CA), prouve l’identité du site Web et permet une connexion chiffrée. Pour illustrer l’ampleur de l’utilisation de TLS et HTTPS, précisons que l’un des principaux émetteurs de certificats TLS en délivre plus de 340 000 par heure. 

Pour sécuriser la communication Internet, le protocole TLS garantit les trois propriétés fondamentales d’un canal sécurisé :

Le protocole Transport Layer Security est efficace car il s’appuie sur des processus cryptographiques pour sécuriser les informations transmises.

La cryptographie vient du mot grec « kryptos », qui signifie « caché». Le but principal de la cryptographie est de sécuriser et d’occulter les communications grâce au chiffrement, un processus par lequel des algorithmes complexes transforment des messages lisibles (texte en clair) en messages codés (texte chiffré). Le texte chiffré ne peut être déchiffré dans un format lisible que par un destinataire autorisé utilisant une clé spécifique.

En cryptographie, comme dans le cas du chiffrement TLS, une clé est une chaîne aléatoire de chiffres ou de lettres. Utilisée avec un algorithme cryptographique, elle permet de chiffrer (verrouiller) ou de déchiffrer (déverrouiller) les informations. Les algorithmes utilisés pour chiffrer et déchiffrer les données transférées sur un réseau se répartissent généralement en deux catégories : la cryptographie à clé secrète et la cryptographie à clé publique.

Également connu sous le nom de chiffrement symétrique ou de chiffrement à clé symétrique, ce système crée une clé partagée unique pour chiffrer et déchiffrer les données sensibles. Le chiffrement symétrique est simple et efficace, mais il repose sur un échange de clés sécurisé et une gestion méticuleuse de ces dernières.

Lors des sessions TLS, la plupart des données sensibles sont envoyées à l’aide de la cryptographie à clé secrète. Le protocole TLS s’appuie sur des fonctions de hachage cryptographiques pour garantir la confidentialité et l’intégrité des données. Ces fonctions génèrent une valeur de hachage fixe à partir des données d’entrée, une sorte d’empreinte digitale numérique que l’on examine avant et après la transmission. Si la valeur de hachage a changé, cela signifie que les données ont été altérées.

Similaire au hachage cryptographique, le code d’authentification de message (MAC) identifie également l’expéditeur. Une clé secrète est appliquée aux messages hachés. Le hachage ainsi obtenu est connu sous le nom de code d’authentification de message haché (HMAC).

Également appelé cryptographie asymétrique ou chiffrement à clé publique, ce système emploie une paire de clés mathématiquement liées (une clé publique et une clé privée) pour chiffrer et déchiffrer les données. Il permet aux utilisateurs et aux systèmes d’échanger des informations sensibles sans avoir à partager une clé secrète au préalable. C’est un peu comme une boîte aux lettres : tout le monde peut y déposer une lettre, mais seul le propriétaire peut l’ouvrir et en récupérer le contenu.

Ces capacités sont un gage de fiabilité lorsqu’elles sont intégrées à l’infrastructure à clés publiques (PKI). Par exemple, les certificats de clé publique (également appelés certificats numériques ou certificats SSL/TLS), associent des clés publiques aux identités vérifiées par l’intermédiaire d’une autorité de certification.

Ils constituent également la base de la signature numérique, une composante des certificats numériques permettant au TLS d’authentifier le client ou le serveur Web. Une fois que le hachage cryptographique du message a été créé, il est chiffré à l’aide de la clé privée de l’expéditeur.

Ce hachage chiffré est la signature numérique. La signature peut être vérifiée par toute personne disposant de la clé publique, ce qui permet de contrôler l’identité de l’expéditeur et l’intégrité des données.

Le protocole TLS se décompose en deux parties : le protocole de négociation TLS et le protocole d’enregistrement TLS. Les étapes varient d’une version TLS à l’autre.

Le protocole de négociation TLS établit une connexion sécurisée entre le client et le serveur Web. Le serveur (et, dans certains cas, le client) est authentifié à l’aide de la cryptographie à clé publique et d’un certificat numérique. Le client et le serveur conviennent ensuite d’une suite de chiffrement (un ensemble d’algorithmes de chiffrement) et procèdent à un échange de clés pour générer des clés de session partagées et sécurisées (clés secrètes pour le chiffrement et le hachage).

Une fois les clés de session mises en place, on considère que la session sécurisée a été configurée. À partir de là, le chiffrement à clé publique n’est plus utilisé, et toutes les données transmises par la suite sont chiffrées et authentifiées à l’aide d’une cryptographie à clé secrète.

(Pour en savoir plus, voir « Quelles sont les étapes de la négociation TLS ? »)

Le protocole d’enregistrement est chargé de sécuriser les données transmises lors de la connexion TLS. Il utilise la suite de chiffrement et les clés négociées pour protéger les données.

La suite de chiffrement définit les algorithmes à utiliser pour l’échange de clés, le chiffrement et l’authentification des messages. Les clés symétriques (secrètes) sont employées pour chiffrer les données sortantes et déchiffrer les données entrantes. Les clés servent également à créer des codes d’authentification des messages pour vérifier l’intégrité des données.

Grâce à ces mécanismes, le protocole d’enregistrement assure l’authentification, l’intégrité et la confidentialité de la connexion.

Les étapes du protocole de négociation TLS varient selon la version TLS. Le processus peut prendre 200 à 300 millisecondes, voire 100 millisecondes seulement. Il va de soi, la durée dépend de la latence, du délai d’aller-retour (RTT), de la performance du serveur et d’autres facteurs liés au réseau.

À titre d’exemple, voici les étapes du protocole TLS 1.3, qui est le plus rapide, le plus récent et le plus sûr.

Le client envoie un message ClientHello avec la version TLS prise en charge (TLS 1.3), des suites de chiffrement, une chaîne d’octets aléatoire (client_random) et un partage de clés éphémères grâce à la méthode d’échange de clés ECDHE (Elliptic Curve Diffie-Hellman Ephemeral).

Le serveur répond par un message ServerHello contenant la suite de chiffrement sélectionnée, une autre chaîne d’octets aléatoire (server_random) et son propre partage de clés éphémères. Cette étape permet de définir les paramètres de l’échange de clés.

Désormais, les deux parties peuvent calculer un secret partagé à l’aide d’ECDHE. Ce secret partagé est utilisé pour obtenir les clés de négociation.

Le serveur envoie ensuite son certificat numérique, un message CertificateVerify (signé avec sa clé privée) et un message Finished (chiffré avec la clé de négociation).

(Facultatif : si le serveur exige l’authentification du client, il envoie un message CertificateRequest. Le client répond ensuite avec son certificat et un message CertificateVerify.)

Le client vérifie que le certificat du serveur est émis par une autorité de certification de confiance, qu’il est valide et non révoqué, et que le domaine correspond. Il vérifie également le message CertificateVerify du serveur à l’aide de la clé publique figurant dans le certificat, ainsi que le message Finished en utilisant la clé d’établissement de session (handshake key).

Le client envoie son propre message Finished à l’aide d’une clé de négociation, et la fin du protocole de négociation est confirmée.

À ce stade, les deux parties se sont vérifiées mutuellement et ont établi une clé secrète partagée. Elles peuvent désormais échanger des messages grâce au chiffrement symétrique.

Les méthodes d’échange de clés permettent aux utilisateurs d’échanger des clés cryptographiques en toute sécurité. Plusieurs méthodes d’échange de clés permettent de mettre en œuvre le protocole TLS. En voici quelques-unes :

Diffie-Hellman est l’une des méthodes d’échange de clés les plus courantes. Il s’agit d’un protocole d’échange de clés asymétrique qui permet à deux parties, sans connaissance préalable l’une de l’autre, de générer une clé secrète commune pour sécuriser leur communication sur un canal non sécurisé. Son efficacité repose sur la difficulté à résoudre le problème du logarithme discret, un problème mathématique complexe qui rend impossible le déchiffrement du secret partagé.

L’échange de clés Diffie-Hellman comporte plusieurs variantes :

• Diffie-Hellman éphémère (DHE) : en DHE, « éphémère » signifie qu’une clé temporaire ou à usage unique est générée pour chaque session. Cela garantit la confidentialité à long terme. En effet, si les clés à long terme sont compromises, les sessions précédentes n’en sont pas affectées. Si la méthode DHE est couramment utilisée avec TLS 1.2, cette version du protocole prend également en charge la méthode DH.
  
  
• Elliptic Curve Diffie-Hellman (ECDH) : similaire à la méthode DH, la méthode s’appuie sur la cryptographie à courbe elliptique, qui offre une plus grande sécurité avec des clés de plus petite taille. Les calculs ECDH sont donc plus rapides et moins gourmands en ressources. Néanmoins, les suites de chiffrement non éphémères sont déconseillées par l’IETF en raison de leur incapacité à assurer une confidentialité persistante.
  
  
• Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) : il s’agit de la version éphémère de l’ECDH, où les clés temporaires sont générées pour chaque session, afin de garantir la confidentialité à long terme. Il s’agit de la méthode d’échange de clés recommandée pour TLS 1.3.

Le RSA est un algorithme de chiffrement asymétrique qui repose sur la difficulté de factoriser les grands nombres pour générer des paires de clés. Il emploie une paire de clés publique-privée pour le chiffrement et le déchiffrement, ce qui le rend adapté à la transmission sécurisée de données et aux signatures numériques. Le chiffrement RSA n’est pas pris en charge dans TLS 1.3 pour l’échange de clés pour des raisons de sécurité (son incapacité à assurer une confidentialité persistante). Cependant, il peut être utilisé à des fins d’authentification.

Une PSK est une clé secrète qui a été partagée entre les deux parties par le biais d’un canal sécurisé avant la session TLS. Les utilisateurs peuvent mettre en place une clé PSK lors d’une négociation TLS, puis l’utiliser pour établir une nouvelle connexion lors d’une autre négociation. C’est ce que l’on appelle une reprise de session par clé PSK. Il est recommandé d’utiliser des PSK avec DHE ou ECDHE pour assurer la confidentialité des données en aval.

Depuis le lancement initial de TLS 1.0 en 1999 (qui était une mise à niveau vers la version 3.0 du SSL), l’IETF a publié trois autres versions TLS :

• TLS 1.1, spécifié dans le document RFC 4346, avril 2006 : cette version apportait des améliorations mineures en matière de sécurité et d’édition, ainsi que des clarifications.
  
  
• TLS 1.2, spécifié dans le document RFC 5246, août 2008 : cette version était une mise à jour de TLS 1.1 qui a considérablement amélioré la flexibilité en matière de négociation des algorithmes cryptographiques.
  
  
• TLS 1.3, défini dans la RFC 8446, août 2018 : cette dernière mise à jour améliore la sécurité, les performances et la confidentialité en réduisant la latence grâce à un temps de zéro aller-retour (0-RTT) et en simplifiant la négociation, entre autres changements.

Il est important de noter que, si la version TLS 1.3 peut être mise en œuvre avec un mode de compatibilité ascendante, elle n’est pas directement compatible avec les versions TLS précédentes.