Comment fonctionne vraiment le chiffrement TLS, étape par étape
Les deux problèmes que TLS doit résoudre à la fois
Chaque fois qu'un navigateur se connecte à un site en https://, il doit résoudre deux problèmes distincts avant qu'un seul octet du contenu réel ne puisse voyager en sécurité. D'abord, le chiffrement — s'assurer que quiconque intercepte le trafic entre vous et le serveur ne voit qu'un bruit incompréhensible au lieu de votre mot de passe ou de votre solde bancaire. Ensuite, tout aussi important, l'authentification — s'assurer que le serveur en face est réellement celui qu'il prétend être, car chiffrer parfaitement une conversation avec un imposteur ne sert à rien. TLS (Transport Layer Security — le nom moderne de ce que beaucoup appellent encore SSL) résout les deux à la fois, et le mécanisme qu'il utilise pour y parvenir est l'une des pièces les plus élégantes de la cryptographie du quotidien.
Pourquoi on ne peut pas simplement chiffrer avec un secret partagé dès le départ
L'approche évidente — « les deux parties se mettent d'accord sur un mot de passe secret et chiffrent tout avec » — a une faille fatale : comment les deux parties se mettent-elles d'accord sur ce secret, au tout début, sur une connexion qui n'est pas encore sécurisée ? Quiconque observe la connexion verrait le secret être échangé et pourrait tout lire ensuite aussi facilement que le destinataire prévu. C'est exactement le problème que la cryptographie asymétrique a été inventée pour résoudre, et c'est la première pièce de la poignée de main TLS.
La cryptographie asymétrique, en un paragraphe
En cryptographie asymétrique (à clé publique), chaque partie possède deux clés liées mathématiquement : une clé publique, qui peut être partagée avec absolument n'importe qui, et une clé privée, qui ne quitte jamais la machine de son propriétaire. Tout ce qui est chiffré avec la clé publique ne peut être déchiffré qu'avec la clé privée correspondante — un serveur peut donc publier sa clé publique ouvertement, et n'importe qui peut l'utiliser pour lui envoyer un message que seul ce serveur peut lire. Cela résout directement le problème « se mettre d'accord sur un secret via un canal non sécurisé » : votre navigateur peut chiffrer quelque chose avec la clé publique du serveur, l'envoyer en clair sur internet sous les yeux de quiconque observe, et seul le vrai serveur — celui qui détient la clé privée correspondante — peut réellement le déchiffrer.
Pourquoi TLS n'utilise pas le chiffrement asymétrique pour tout
Si la cryptographie asymétrique résout le problème, pourquoi TLS ne chiffre-t-il pas simplement tout le chargement de la page avec ? Parce que le chiffrement asymétrique est coûteux en calcul — nettement plus lent que l'alternative — alors que le reste de la session de navigation peut impliquer des milliers de paquets. TLS utilise donc la cryptographie asymétrique pour exactement une tâche : se mettre d'accord de façon sécurisée sur une clé de session, un secret partagé bien plus simple, tout au début de la connexion. Une fois que les deux parties disposent de cette clé de session, elles passent au chiffrement symétrique — la même clé verrouillant et déverrouillant les données des deux côtés — ce qui est nettement plus rapide et gère le gros du trafic, images et appels d'API pour le reste de la session. Ce relais — un échange de clé coûteux mais sécurisé, suivi d'un chiffrement en masse rapide et bon marché — est l'astuce centrale derrière presque tous les systèmes de chiffrement pratiques, pas seulement TLS.
La partie qui prouve à qui vous parlez réellement
Résoudre uniquement le chiffrement laisse encore le problème de l'authentification : n'importe qui peut générer sa propre paire de clés publique/privée et prétendre être votre banque. C'est là qu'interviennent les certificats et les autorités de certification (CA). Un certificat est un fichier qui associe la clé publique d'un serveur à son nom de domaine, signé numériquement par une autorité de certification — une organisation en laquelle votre navigateur et votre système d'exploitation ont déjà confiance, cette confiance étant intégrée à l'avance sous forme d'une liste de clés publiques de CA connues, livrée avec chaque navigateur et système. Quand votre navigateur se connecte à un serveur, celui-ci présente son certificat, et votre navigateur vérifie la signature de ce certificat par rapport à la clé publique connue de la CA. Si la signature est valide, votre navigateur peut faire confiance au fait qu'une CA a vérifié, à un moment donné, que cette clé publique précise appartient réellement à ce domaine précis — ce qui empêche réellement un attaquant de simplement générer ses propres clés et de se faire passer pour votre banque, puisqu'il aurait aussi besoin qu'une CA signe un certificat affirmant que sa clé appartient au domaine de votre banque, ce qu'une CA ne fera pas sans d'abord vérifier la propriété du domaine.
Assembler toute la poignée de main
Quand vous vous connectez à un site HTTPS, à peu près cette séquence se produit avant qu'aucun contenu de page ne circule : votre navigateur dit bonjour et liste les méthodes de chiffrement qu'il prend en charge ; le serveur répond avec son certificat et choisit une méthode commune ; votre navigateur vérifie ce certificat par rapport à sa liste de CA de confiance ; navigateur et serveur utilisent alors la cryptographie asymétrique pour se mettre d'accord de façon sécurisée sur une clé de session, chacun apportant de l'aléatoire pour que cette clé soit unique à cette connexion précise ; et à partir de là, tout — le HTML réel, les images, les envois de formulaires — circule chiffré avec cette clé de session symétrique rapide. Toute cette séquence se termine généralement en bien moins d'une seconde, ce qui explique en partie pourquoi on oublie facilement qu'elle a lieu.
Pourquoi « le cadenas » est une barre plus basse qu'on ne le pense
L'icône de cadenas dans la barre d'adresse d'un navigateur signifie que la connexion est chiffrée et que le certificat est valide pour ce domaine — des garanties réellement utiles. Elle ne signifie pas que le site lui-même est digne de confiance, sûr ou légitime ; les autorités de certification vérifient que vous contrôlez un domaine, pas que le contenu que vous y servez est honnête. Un site de phishing nommé paypa1-securite.com peut avoir un certificat parfaitement valide et un cadenas parfaitement légitime, car rien dans la poignée de main TLS ne vérifie si un nom de domaine tente d'usurper une autre entreprise réelle. Comprendre ce que TLS vérifie réellement — cette clé précise appartient à ce domaine précis, et le trafic vers lui est chiffré — par opposition à ce qu'il ne vérifie pas — si ce domaine est bien celui que vous vouliez visiter — fait toute la différence entre un cadenas qui est un signal modérément utile et un cadenas auquel on accorde plus de confiance qu'il ne le mérite.