HTTPS de bout en bout
Tu tapes une adresse, tu appuies sur entrée, et avant même de voir l'écran il y a déjà, à gauche de l'adresse, un pictogramme qui dit : la connexion est sécurisée. Entre les deux, il y a eu une conversation. En ces quelques centaines de millisecondes, ton navigateur et le serveur se sont mis d'accord sur un secret, ont échangé et vérifié une pièce justificative, et sont passés au chiffrement. Ce chapitre déroule ce qui se passe — et il n'y a aucune nouvelle mathématique. Tout ce dont tu as besoin est déjà dans les chapitres précédents. Ici, tu les vois travailler ensemble.
Les mots dont tu as besoin
- HTTPS
- Le web ordinaire (HTTP) avec une couche chiffrée en dessous. Cette
couche s'appelle TLS.
https://dans la barre d'adresse ne veut rien dire d'autre que : il y a du TLS là-dessous. - TLS
- Transport Layer Security. La version actuelle est TLS 1.3, et elle est décrite dans la RFC 8446, d'août 2018. Une RFC est le document public dans lequel se trouve une norme d'internet ; tout le monde peut la lire.
- Handshake
- Littéralement : la poignée de main. Les tout premiers messages dans lesquels le navigateur et le serveur conviennent de la manière dont ils vont continuer à se parler. Ensuite commence le vrai trafic.
- Aller-retour
- Une fois dans un sens et une fois dans l'autre à travers le réseau. En anglais round trip, abrégé RTT. C'est l'unité dans laquelle la vitesse compte ici : pas en calculs, mais en nombre de fois où tu dois attendre l'autre.
- Suite de chiffrement
- Le petit paquet d'accords sur les algorithmes utilisés : quel chiffrement, quelle fonction de hachage. Le navigateur et le serveur en ont chacun une liste, et ils en choisissent une ensemble.
- SNI
- Server Name Indication. Le petit champ dans lequel ton navigateur dit d'emblée quel site il veut. Sur une seule adresse IP il y a souvent des centaines de sites, donc le serveur doit le savoir avant de pouvoir envoyer le bon certificat.
- Man-in-the-middle
- Quelqu'un qui se place entre toi et le serveur et fait croire à chacun des deux qu'il est l'autre. Il lit et modifie alors tout, sans qu'aucun des deux s'en aperçoive.
Le handshake, étape par étape
- ClientHello. Ton navigateur envoie en premier un message avec : les versions de TLS qu'il sait faire, les suites de chiffrement qu'il connaît, le site qu'il veut (c'est le SNI) — et déjà sa moitié de l'échange de clés. Il n'attend donc pas que le serveur ait choisi ; il parie sur ce que le serveur voudra probablement et envoie sa moitié publique d'avance.
- ServerHello. Le serveur choisit une version et une suite de chiffrement, et renvoie sa propre moitié. À ce moment-là, ils peuvent tous les deux, chacun de son côté, calculer le même nombre : le secret partagé. C'est exactement le tour de passe-passe avec la peinture de chapitre 5, le plus souvent sur une courbe elliptique. Il y a maintenant une clé, et elle n'est jamais passée sur la ligne.
- Le certificat et une signature. À partir d'ici, tout est déjà chiffré — y compris ce qui suit. Le serveur envoie son certificat (chapitre 7.2) et par-dessus une signature sur toute la conversation jusqu'ici. C'est cette signature qui compte : tout le monde peut copier un certificat, mais seul celui qui possède la clé privée correspondante peut en apposer une. C'est ainsi que tu sais que tu parles au vrai serveur et pas à un man-in-the-middle.
- Ton navigateur vérifie. Trois choses, et les trois doivent être justes. La chaîne de signatures de ce certificat peut-elle être suivie jusqu'à un certificat racine auquel il fait confiance ? Le nom dans le certificat est-il le même que ce que tu as tapé ? Sommes-nous dans les dates de validité ? Un seul non et tu n'obtiens pas de cadenas mais un écran d'avertissement.
- La suite en symétrique. À partir de maintenant, tout — la page, les images, ton mot de passe, chaque clic — est chiffré symétriquement avec AES-GCM. C'est chapitre 4, et le fait que les maths lourdes ne servent qu'au début et que le reste aille vite, c'est chapitre 7.3.
Quel chapitre se trouve dans quelle étape
| Étape | Ce qui se passe | Tu le connaissais déjà de |
|---|---|---|
| 1–2 | Envoyer chacun une moitié, calculer chacun le même secret | chapitre 5, sur les courbes de chapitre 6.2 |
| 3 | Une signature sur la conversation, pour que tu saches qui parle | chapitre 7.1 |
| 3–4 | Le certificat et la chaîne jusqu'à une racine de confiance | chapitre 7.2 |
| 5 | Tout le reste de la visite, chiffré rapidement avec AES-GCM | chapitre 4 |
| 1–5 | Des maths lentes pour la clé, des rapides pour les données | chapitre 7.3 |
Un aller-retour au lieu de deux
Que le navigateur envoie sa moitié de l'échange de clés dès son tout premier message, ça a l'air d'un détail. C'est le plus grand changement de TLS 1.3 par rapport à son prédécesseur TLS 1.2. Là, ça se passait ainsi : d'abord le navigateur demandait ce que le serveur savait faire, puis le serveur répondait, et seulement après commençait l'échange de clés. Deux allers-retours avant qu'une seule lettre de contenu ne passe sur la ligne. TLS 1.3 le fait en un seul aller-retour.
| TLS 1.2 | TLS 1.3 | |
|---|---|---|
| Allers-retours pour le handshake | 2 | 1 |
| Approche | d'abord se concerter, puis échanger la clé | parier et échanger la clé tout de suite ; si le pari est faux, alors seulement se concerter |
| Certificat du serveur | passe en clair sur la ligne | passe chiffré, car il y a déjà une clé |
Sur une connexion où un aller-retour coûte 50 millisecondes, ça fait donc gagner 50 millisecondes par nouvelle connexion — et une page va souvent chercher ses images, ses polices et ses scripts sur une poignée de domaines différents, chacun avec sa propre connexion. C'est ainsi que la version plus récente est devenue à la fois mieux sécurisée et plus rapide.
Ce que le cadenas veut dire et ce qu'il ne veut pas dire
| Oui | Non |
|---|---|
| Tout ce que tu envoies et reçois est chiffré. Celui qui écoute sur le wifi de l'école ou du train ne lit rien. | Que le site soit honnête. Le cadenas ne dit rien sur qui est derrière ni sur ce qu'ils font de tes données. |
| Le nom dans le certificat est le même que celui que tu as tapé, et une autorité de certification a signé pour ça. | Que le nom que tu as tapé soit celui que tu voulais. Si tu tapes une lettre de travers, le certificat de cet autre site est parfaitement en ordre. |
Ce deuxième point n'est pas un problème théorique. Un certificat ne coûte aujourd'hui plus rien et s'obtient en quelques minutes, y compris pour qui construit une fausse page de connexion. Plus de neuf sites de phishing sur dix ont un certificat valide et donc un cadenas — en 2019 c'était encore environ six sur dix. Le cadenas prouve que personne ne lit en chemin — pas que la destination soit digne de confiance.
Google a étudié en 2021 ce que les gens croyaient que le cadenas voulait dire. 11 pour cent avaient juste ; les autres le lisaient comme un label de qualité. C'est pourquoi le cadenas a été remplacé dans Chrome, depuis la version 117 de septembre 2023, par un pictogramme neutre avec deux curseurs. Non pas parce que quelque chose a changé à la sécurité, mais parce que le symbole promettait la mauvaise chose.
Fais-le toi-même, tout de suite. Clique sur le pictogramme à gauche de l'adresse web ci-dessus — dans Chrome et Edge les deux curseurs, dans Firefox encore un cadenas. Si tu cherches ton chemin vers La connexion est sécurisée puis vers le certificat, tu vois exactement les choses de l'étape 4 : pour quel nom il est valable, qui l'a délivré, entre quelles deux dates il vaut, et la chaîne au-dessus jusqu'à la racine. C'est le certificat du site que tu es en train de lire.
Ce qu'un espion voit encore
Chiffré ne veut pas dire invisible. Quelqu'un qui peut lire le trafic sur ton réseau — ton fournisseur d'accès, l'administrateur du wifi — sait encore quelques petites choses.
| Ce qu'il voit | Ce qu'il ne voit pas |
|---|---|
| Quel domaine tu visites. Deux fois même : dans la requête DNS avec laquelle ton navigateur cherche l'adresse IP, et dans le SNI du ClientHello, qui doit être en clair puisque sinon le serveur ne sait pas quel certificat envoyer. | Quelle page de ce domaine. Que tu étais sur un site, oui ; que tu y lisais cet article, non. |
| Combien de données vont et viennent, et quand. À partir d'un motif de tailles de paquets et de pauses, on peut parfois deviner étonnamment beaucoup. | Le contenu. Ta recherche, ton mot de passe, ton message, la page elle-même. Il n'y accède pas. |
On travaille à colmater cette première fuite. Encrypted Client Hello (ECH) emballe le vrai ClientHello — avec le vrai SNI dedans — chiffré dans une enveloppe d'apparence anodine. La clé pour ça, ton navigateur va la chercher dans le DNS. Chrome l'active par défaut depuis la version 117 (septembre 2023), Firefox depuis la version 119 (octobre 2023), et depuis mars 2026 c'est une norme d'internet officielle : la RFC 9849.
À moitié fermé donc, pas complètement. Ça ne marche que si le site joue le jeu et publie sa clé dans le DNS, et c'est loin d'être le cas de tout le monde. Et ta requête DNS reste visible à moins qu'elle ne passe elle aussi chiffrée (DNS over HTTPS). L'adresse IP vers laquelle va ta connexion, il la voit de toute façon : sans adresse, aucun paquet n'arrive.
HSTS : ne reviens jamais en http
Il y a un moment où ça tourne mal. Si tu tapes site.be sans
https:// devant, ton navigateur essaie traditionnellement
d'abord en http ordinaire — non chiffré. Cette toute première requête,
un man-in-the-middle peut l'intercepter et la détourner vers sa propre copie,
et alors le reste de ta visite lui appartient. C'est pourquoi un site peut
joindre à sa réponse une ligne qui dit : retiens que chez moi tu ne
peux plus venir qu'en https, avec une date d'expiration. Ça s'appelle
HSTS, décrit dans la RFC 6797 de novembre 2012. Ton navigateur le retient, et
n'essaie ensuite même plus en http — même pas si tu le tapes, et même
pas si tu veux cliquer sur « continuer quand même ». Il ne reste
comme trou que cette toute première visite, et pour ça les navigateurs
tiennent une liste intégrée de domaines qui ont toujours été en https.
Voici les maths : prouver un protocole au lieu de l'essayer
Un handshake n'est pas un calcul mais une conversation : qui dit quoi, dans quel ordre, et qu'as-tu le droit d'en conclure. À la question « un attaquant peut-il, en interceptant, en répétant ou en permutant des messages, finir un jour avec une clé qu'il ne devrait pas avoir ? », tu ne peux pas répondre en essayant. Il y a trop d'ordres possibles. Tu dois le prouver.
C'est exactement ce qui s'est passé avec TLS 1.3, et c'était une première : la conception a été vérifiée alors qu'elle n'était encore qu'un brouillon, pas après coup. Cas Cremers et quatre collègues ont coulé la version 21 du brouillon dans l'assistant de preuve Tamarin et lui ont fait parcourir les possibilités d'attaque — le travail a paru à la conférence CCS de 2017, presque un an avant que la RFC 8446 n'existe, en août 2018. Les versions précédentes de TLS n'étaient pas nées comme ça, et on y a trouvé des trous pendant des années.
Cette discipline s'appelle la vérification formelle, et elle se situe à la frontière des mathématiques et de l'informatique : tu écris un protocole en logique et tu laisses un programme parcourir tous les cas possibles. Pas « on l'a testé et ça a l'air de marcher », mais « on a prouvé que l'autre est impossible ». On l'utilise aussi pour la signalisation ferroviaire, les puces et les logiciels d'avion — partout où « on a essayé un moment » n'est pas une réponse.