Le protocole de sécurisation des échanges TLS (ancien SSL) et HTTPS

Le protocole TLS pour Transport Layer Security ou Sécurité de la Couche de Transport en français est un protocole de sécurisation des échanges (au sens large) sur Internet. TLS crypte les données envoyées sur Internet pour garantir que les données transmises ne soient pas interceptées par des entités malveillantes.

Le protocole TLS est le successeur de l’ancien protocole SSL (Secure Sockets Layer).

 

L’origine de TLS : le protocole SSL

Le protocole SSL a été originellement créé par la société Netscape. Son objectif principal était de permettre de développement les achats sur le net en fournissant un gage de confiance aux utilisateurs. La session chiffrée est utilisée pour empêcher un tiers d’intercepter des données sensibles transitant par le réseau. L’IETF (groupe chargé de la standardisation de certains protocoles et notamment chargé de l’évolution de HTTP) a ensuite continué son développement en le renommant TLS.

 

Qu’est-ce que TLS et à quoi sert ce protocole ?

TLS est un protocole cryptographique qui assure la sécurité de bout en bout des données envoyées entre les applications sur Internet.

Le protocole TLS fonctionne au-dessus de la couche transport des modèles OSI et TCP/IP. Théoriquement, le cryptage des données devrait être du ressort de la couche présentation du modèle OSI même si en pratique certaines applications traitent TLS comme si il appartenait à la couche transport.

TLS est aujourd’hui très largement utilisé sur Internet notamment car il n’implique pas une modification des protocoles de la couche application comme HTTP. Les protocoles comme HTTP vont simplement être implémentés au-dessus de TLS. Par exemple, le protocole HTTPS est simplement la variante sécurisée du protocole HTTP.

TLS permet d’initialiser une connexion client-serveur privée (ou sécurisée) en utilisant une cryptographie symétrique pour crypter les données transmises. Les clés de ce cryptage symétrique sont générées de manière unique pour chaque connexion et sont basées sur un secret partagé qui a été négocié au début de la session. La négociation de ce secret partagé est à la fois sécurisée (le secret négocié n’est pas accessible aux écoutes et ne peut être obtenu, même par un attaquant qui se place au milieu de la connexion) et fiable (aucun attaquant ne peut modifier les communications pendant la négociation sans être détectée).

De plus, la connexion est fiable car chaque message transmis comprend un contrôle d’intégrité du message à l’aide d’un code d’authentification de message pour éviter toute perte ou altération non détectée des données pendant la transmission.

Enfin, l’authentification du serveur (et de manière optionnelle du client) peut être réalisée à l’aide de clefs cryptographiques publiques afin de s’assurer qu’un attaquant n’est pas en train d’usurper l’identité de l’une des deux parties (client ou serveur).

Attention : il faut savoir que TLS prend en charge de nombreuses méthodes différentes pour l’échange de clés, le chiffrement des données et l’authentification de l’intégrité des messages. Par conséquent, la configuration sécurisée de TLS implique de nombreux paramètres configurables, et tous les choix ne fournissent pas toutes les propriétés liées à la confidentialité.

 

Historique des versions SSL et TLS

Le protocole SSL a connu 3 versions (la première n’ayant jamais été mise en œuvre) : SSL 1.0 en 1994, SSL 2.0 en février 1995 et SSL 3.0 en novembre 1996.

Le protocole TLS a connu quatre versions : TLS v1.0 en 1999, TLS v1.1 en 2006, TLS v1.2 en 2008 et TLS v1.3 en 2018.

 

Fonctionnement des échanges avec TLS

Lorsqu’un utilisateur tente d’accéder à un site web qui utilise TLS, le client (navigateur de l’utilisateur) commence par envoyer une demande de mise en place de connexion sécurisée par TLS au serveur.

Le serveur renvoie alors son certificat contenant sa clé publique, ses informations (nom de la société, adresse postale, pays, e-mail de contact…) et une signature numérique qui permettent de l’authentifier.

Le certificat est un certificat numérique X.509 délivré par une autorité de certification (AC). Ce certificat peut être vu comme une carte d’identité numérique. Il permet d’identifier une entité et peut également être utilisé pour chiffrer des échanges.

Note : certaines applications utilisent également TLS pour authentifier le client, afin d’obtenir une authentification forte.

Une fois le certificat envoyé, le client vérifie si celui-ci est valide. Pour cela, il vérifie la signature numérique du certificat du serveur en utilisant les clés publiques contenues dans les certificats des autorités de certifications intégrés par défaut dans le navigateur.

Si la validité du certificat est confirmée, le client génère une clé de chiffrement symétrique ou « clef de session » ou « secret » à partir de la clé publique contenue dans le certificat du serveur puis transmet cette clé de session au serveur. La clé de chiffrement symétrique est générée à partir d’un chiffrement asymétrique.

Le serveur déchiffre la clé de session envoyée par le client grâce à sa clé privée puis le client et le serveur commencent finalement à s’échanger des données en les chiffrant en utilisant la clef de session.

Dès la fin de la connexion, le serveur révoque la clé de session afin qu’elle ne puisse plus être utilisée.