TLS & HTTPS Explained

1TLS n'empêche personne d'écouter, il rend l'écoute inutile

Le cours part d'un formulaire envoyé par un navigateur, avec l'identifiant « Wally » et le mot de passe « secret » (leçon 1). Wally Warthog est le pseudonyme du professeur (leçon 13). Le fil, c'est le réseau entre le navigateur et le serveur. Là, n'importe quelle machine de passage, un routeur ou un Wi-Fi par exemple, peut copier le formulaire. Clyde est direct. « TLS n'empêche personne d'intercepter les données, car une fois sur le fil, tout le monde peut se servir » (leçon 9).

TLS ne cache donc pas ce qui passe sur le fil. TLS fait trois promesses sur ce contenu (leçon 9) :

• confidentialité : celui qui intercepte ne lit que du charabia.
• intégrité : personne n'a modifié le message en route.
• authenticité : vous parlez au serveur que vous vouliez joindre, pas à un pirate qui se fait passer pour lui.

Dans la suite, le pirate est celui qui écoute ou modifie ce qui passe sur le fil.

L'intégrité repose sur le hachage : le calcul d'une empreinte, un court résumé du message. Le message part avec son empreinte, et le destinataire la recalcule pour comparer (leçon 15). Changez une lettre, l'empreinte change entièrement (leçon 15). Mais « n'importe qui peut produire une empreinte » (leçon 15). Un pirate qui modifie le message envoie donc aussi une nouvelle empreinte, et le destinataire ne voit rien.

Pour déjouer le pirate, l'empreinte doit dépendre d'une valeur secrète que le pirate ignore. Sans elle, le pirate ne peut pas fabriquer l'empreinte qui convient (leçons 16 et 17). Une clé est une telle valeur secrète, une longue suite de chiffres. Elle a deux usages. Elle entre dans un calcul d'empreinte. Elle sert aussi à chiffrer, c'est-à-dire rendre un message illisible, et à déchiffrer, c'est-à-dire le rendre de nouveau lisible. Ce second usage tient la confidentialité.

2Une clé lente pour se mettre d'accord, une clé rapide pour parler

Reste un problème : comment le navigateur et un serveur inconnu se mettent-ils d'accord sur une clé, devant tout le réseau ? Le cours présente deux familles d'algorithmes de chiffrement, c'est-à-dire de méthodes de calcul, et TLS a besoin des deux (leçon 9) :

• chiffrement symétrique : une seule clé chiffre et déchiffre. C'est rapide. Le cours cite AES (Advanced Encryption Standard) en exemple (leçon 7). Les deux côtés doivent pourtant déjà avoir la même clé.
• chiffrement asymétrique : une paire de clés. La clé publique se donne à tous, et elle chiffre. La clé privée reste chez son propriétaire, et elle seule déchiffre. Ce chiffrement est « beaucoup plus lent que le chiffrement symétrique » (leçon 9).

Mon image, qui n'est pas du cours : le serveur distribue des cadenas ouverts, sa clé publique. N'importe qui peut en fermer un sur un colis, mais seul le serveur a la clé du cadenas, sa clé privée. Dans l'ancienne méthode, RSA, le navigateur s'en sert au début de la connexion pour lui envoyer un secret.

Des chiffres que le cours ne donne pas, mesurés par moi : sur un portable récent (processeur AMD, Go 1.26, médiane de 6 mesures), une opération de chaque famille. La colonne de droite est un calcul : 1 Mo découpé en blocs de 190 octets, la taille maximale que RSA-2048 accepte à la fois.

Opération	Ce qu'elle traite	Temps par opération	Pour 1 Mo
AES-256-GCM, chiffrer (famille rapide)	1 Ko	0,19 µs	0,2 ms
RSA-2048, déchiffrer (famille lente)	190 octets au plus	0,74 ms	plus de 4 s
X25519 (Diffie-Hellman), s'accorder sur un secret	aucune donnée	33 µs	sans objet

Un échange de clés ne chiffre aucune donnée : il sert seulement à s'accorder sur le secret (idée 5). Pour les données, l'écart est d'environ 20 000 fois en faveur d'AES. TLS n'emploie donc la famille lente qu'une fois, au début.

TLS combine les deux. Au début, la famille lente sert à mettre les deux côtés d'accord sur un secret commun. Chaque côté en tire ensuite les mêmes clés rapides (leçon 12). Après, tout passe en symétrique (leçons 9 et 11). Ces clés rapides s'appellent les clés de session, car elles ne vivent que le temps d'une connexion (leçon 7).

Il y a plusieurs façons de s'accorder sur le secret commun (leçon 12). Le cours en montre deux : RSA, l'ancienne, et Diffie-Hellman, celle de TLS 1.3. L'idée 5 détaille les deux.

Chaque outil tient ainsi une promesse de l'idée 1. Le chiffrement symétrique tient la confidentialité de tout le trafic. Le hachage, avec un secret, tient l'intégrité. La signature, vue ensuite, tient l'authenticité.

3N'importe qui fabrique des clés, d'où l'autorité de certification

La paire asymétrique sait aussi signer. Pour signer, on inverse les rôles de la paire : la clé privée chiffre l'empreinte du texte, et ce résultat est la signature. Le texte voyage avec elle. Le destinataire déchiffre la signature avec la clé publique, ce qui redonne l'empreinte, et la compare à celle qu'il calcule lui-même (leçons 13 et 16). Seul le détenteur de la clé privée peut produire une signature qui concorde. Elle prouve donc deux choses : le texte n'a pas bougé, et il vient de ce détenteur. Ce n'est pas un secret, car tout le monde peut déchiffrer avec la clé publique, et c'est voulu.

Cette preuve bute pourtant sur un fait. Au début de la connexion, le serveur envoie sa clé publique au navigateur (leçon 12). Mais « n'importe qui peut générer des clés publiques et privées » (leçon 19). Un pirate sur le chemin peut envoyer la sienne en se faisant passer pour piggybank.com, la banque fictive. Le navigateur lui confierait alors ses secrets.

La parade est un tiers que le navigateur connaît déjà : l'autorité de certification (CA, certificate authority). Le serveur envoie à la CA une CSR (certificate signing request, demande de signature) avec sa clé publique et son domaine. La CA vérifie que le serveur contrôle ce domaine. Par exemple, elle lui fait déposer un fichier, puis elle vient le lire (leçon 20). Puis elle signe. Le résultat est le certificat : un fichier public qui dit « cette clé appartient à ce domaine », signé par la CA.

Le navigateur croit la CA parce que la clé publique de la CA est déjà chez vous. Système et navigateur arrivent avec une liste de CA de confiance, le magasin de confiance (leçon 21). Quelques CA ne peuvent pas gérer tous les certificats du monde. Elles délèguent donc à des intermédiaires, comme un PDG à ses managers (leçon 21). Le certificat d'un site est ainsi signé par un intermédiaire. Le certificat de l'intermédiaire est signé par une racine, une CA du sommet qui ne dépend d'aucune autre. Cette suite site, intermédiaire, racine s'appelle la chaîne de confiance.

Une racine signe son propre certificat : on dit qu'il est auto-signé. Elle n'est pas crue sur parole, car elle figure déjà dans le magasin de confiance de votre système. Sur le certificat de google.com, la racine « GTS Root R1 » s'est signée elle-même, et Windows l'a déjà (leçon 29). GTS signifie Google Trust Services (hors cours, à vérifier sur pki.goog).

Pour ne pas mélanger les deux moments, voici ce qui se passe avant toute visite, puis à chaque visite.

Avant, une seule fois (puis à chaque renouvellement du certificat) :

• Le serveur fabrique sa paire de clés durable et prouve à la CA qu'il contrôle le domaine, comme dans la figure du début de l'idée.
• La CA signe, avec sa clé privée, l'empreinte du certificat : le domaine et la clé publique du serveur. Cette signature est le certificat, que le serveur garde.
• De son côté, le navigateur arrive avec les certificats des CA racines. Il n'a rien d'autre à télécharger.

À chaque visite :

• Le navigateur fabrique une paire de clés propre à cette connexion. Elle ne sert qu'à calculer le secret commun (idée 5).
• Le serveur lui envoie son certificat, avec ceux des intermédiaires.
• Le navigateur remonte la chaîne : il vérifie chaque signature avec la clé publique du maillon au-dessus, jusqu'à une racine qu'il connaît déjà.
• Seulement ensuite, la requête de la page part, chiffrée avec les clés de session.

4Le navigateur contrôle la date, la signature et le domaine

Le certificat arrive au début de la connexion, pendant la poignée de main (handshake), l'échange d'ouverture que l'idée 5 détaille. Que fait alors le navigateur ? Il fait trois contrôles :

• la date du jour tombe dans la période de validité.
• la signature vient d'une CA de confiance.
• le domaine du certificat est celui du site demandé.

Un seul contrôle raté suffit à faire rejeter le certificat. Voici quel contrôle arrête quel cas :

Certificat présenté	Date	Signature	Domaine	Verdict
Valide, délivré pour ce site	✓	✓	✓	accepté
Expiré	✗	✓	✓	rejeté
Faux piggybank.com fabriqué par un pirate	✓	✗	✓	rejeté
Vrai certificat, mais d'un autre site	✓	✓	✗	rejeté

La signature se contrôle en deux calculs (leçon 22). Le navigateur calcule l'empreinte du certificat. Puis il déchiffre la signature avec la clé publique de la CA, ce qui redonne l'empreinte calculée par la CA. Les deux doivent être égales.

Un certificat falsifié, comme un faux piggybank.com, échoue, car le pirate n'a pas la clé privée de la CA. La seule exception est le vol de cette clé. Clyde la reconnaît : c'est « arrivé par le passé », mais très rare (leçon 22).

5En TLS 1.3, tout est chiffré après les deux premiers messages

Avant le détail, le film d'une connexion, dans l'ordre. Pour se la représenter, imaginez deux personnes qui veulent se parler discrètement dans une salle pleine de monde. TLS s'ouvre avant HTTP et ne passe pas par lui.

1. Le TCP, la façon dont deux machines ouvrent une ligne fiable entre elles, vient d'abord. C'est un tuyau brut, sans chiffrement et sans HTTP : tout ce qu'on y dit s'entend dans la salle.
2. Les deux premiers messages TLS partent en clair, comme des cartes postales que tout le monde peut lire. On n'y met donc que des choses sans danger, des parties publiques.
3. Chaque côté calcule le même secret chez lui, sans l'envoyer. C'est le jeu des peintres, un peu plus bas.
4. Dès lors, tout est chiffré avec des clés tirées de ce secret. La conversation continue derrière une cloison opaque : la salle voit des gens parler et n'entend que du bruit.
5. Les requêtes HTTP ne partent qu'à ce moment, à l'intérieur du tunnel chiffré. HTTPS, c'est du HTTP posé dans un tunnel TLS.

Il reste à voir dans quel ordre clés, signature et certificat se croisent pendant la poignée de main. En TLS 1.3, la version actuelle, elle commence par deux messages en clair, c'est-à-dire non chiffrés (leçons 23 et 24) :

1. Le ClientHello, le « bonjour » du client. Le navigateur annonce ses versions de TLS, ses suites de chiffrement (les combinaisons de méthodes acceptées) et un nombre tiré au hasard. Ce nombre servira à fabriquer les clés de cette connexion (leçon 12). Il joint une clé publique d'échange, dans un champ nommé key_share.
2. Le ServerHello, le « bonjour » du serveur. Le serveur choisit une suite et renvoie son propre nombre tiré au hasard et sa propre clé publique d'échange.

Avec ces deux clés publiques, chaque côté calcule le même secret commun sans l'envoyer. C'est l'algorithme de Diffie-Hellman. Chaque côté a fabriqué pour cette connexion sa propre paire de clés (leçon 26). Sa clé publique voyage dans le Hello, sa clé privée reste chez lui. Chacun mélange sa clé privée avec la clé publique de l'autre, et les deux tombent sur le même résultat.

Mon image, qui n'est pas du cours : deux peintres partent d'une même couleur publique. Chacun y mêle sa couleur secrète, sa clé privée, puis ils s'échangent leurs mélanges, leurs clés publiques. Chacun ajoute alors sa couleur secrète au mélange de l'autre. Les deux obtiennent la même teinte. Un pirate qui a vu les mélanges ne sait pas séparer les couleurs pour la refaire.

Ce secret commun joue le rôle annoncé à l'idée 2. Chaque côté en tire les mêmes clés de session, et tout ce qui suit le ServerHello est chiffré avec elles (leçons 12 et 26). Sur une capture de Wikipedia, Clyde constate : « à partir de là, tout est chiffré, on ne peut pas le lire » (leçon 24).

Le serveur envoie ensuite son certificat, qui passe déjà chiffré, à l'abri derrière la cloison. Le certificat étant public, n'importe qui peut le présenter : le serveur doit aussi prouver qu'il détient la clé privée. En TLS 1.3, hors cours, une signature s'en charge (voir l'encadré de l'idée 4). Chaque côté envoie enfin un message Finished (« terminé »), chiffré avec les clés de session qu'il vient de fabriquer. Si l'autre arrive à le lire, c'est que les deux côtés ont les mêmes clés (leçon 27). Puis les requêtes HTTP partent.

Avant TLS 1.3, la méthode de TLS 1.2 faisait autrement : Diffie-Hellman « remplace » RSA (Rivest-Shamir-Adleman) (leçons 12 et 24). Le client tire un secret commun au hasard, le chiffre avec la clé publique du serveur et l'envoie. C'est un colis fermé avec l'un des cadenas ouverts de l'idée 2. Seul le serveur l'ouvre, avec sa clé privée. Les deux côtés mêlent ensuite ce secret aux deux nombres tirés au hasard pour obtenir les clés de session (leçon 12). La preuve d'identité vient alors toute seule : un faux serveur ne sait pas ouvrir le colis, donc il ne peut pas continuer (leçon 27).

Les captures du cours sur google.com viennent de HTTP/3, qui roule sur QUIC, bâti sur UDP, au lieu de TCP (deux façons d'envoyer des paquets). La poignée de main TLS y reste la même (leçons 7 et 23). Cela compte pour l'idée 7, où le HTML reste illisible.

Un détail déroute : le ClientHello affiche « TLS 1.2 ». C'est une concession aux vieux pare-feux, des filtres réseau qui renvoyaient des erreurs sans cette valeur. La vraie version est dans un champ complémentaire, l'extension supported_versions (leçon 24).

6Le navigateur propose deux clés d'échange, et la grosse résiste à l'ordinateur quantique

Le champ key_share de l'idée 5 portait jusque-là une clé de 32 octets, et il a grossi : voici pourquoi. Un ordinateur quantique assez puissant pourrait casser les échanges de clés d'aujourd'hui (leçons 25 et 26). Cette machine résout des calculs hors de portée des machines actuelles. Le NIST (National Institute of Standards and Technology), l'agence américaine des normes, a donc publié de nouveaux algorithmes. Clyde date cette publication : « le NIST n'a produit sa série finale de standards post-quantiques qu'en août 2024 » (leçon 26). L'adoption par les navigateurs reste floue : « difficile de dire quand, fin 2023 ou quelque part en 2024 » (leçon 26).

Les navigateurs ne misent pas tout sur la méthode neuve : ils portent ceinture et bretelles. Ils proposent un échange hybride, qui empile deux méthodes. X25519 est le Diffie-Hellman de l'idée 5, les deux peintres, calculé sur une courbe elliptique, une courbe mathématique qui permet des clés courtes. Elle a fait ses preuves, mais un ordinateur quantique pourrait la casser. ML-KEM est la méthode post-quantique du NIST, beaucoup plus récente. Empiler les deux rend l'échange très dur à casser (leçon 26). Hors cours, d'après le brouillon de l'IETF cité plus bas (§2.1) : il reste sûr tant qu'une des deux méthodes tient.

ML-KEM ne marche pas comme les peintres. KEM veut dire Key Encapsulation Mechanism, mécanisme d'encapsulation de clé : c'est un colis. Le client envoie un cadenas ouvert, sa clé publique ML-KEM. Le serveur invente un secret, l'enferme dans un colis fermé avec ce cadenas et le renvoie. Seul le client a la clé, donc seul lui l'ouvre.

Le client annonce les méthodes qu'il connaît dans l'extension supported_groups. Chaque méthode a un numéro de groupe. Le groupe 4588 désigne la combinaison X25519 plus ML-KEM (leçon 26). Dans le ClientHello de google.com, Wireshark montre deux key_share. Le premier fait 1216 octets : c'est l'hybride, les deux clés mises bout à bout (leçons 24 et 26). Le second, de 32 octets, est un X25519 seul, en secours si le serveur ignore l'hybride. Google prend l'hybride, donc « la seconde clé n'est pas utilisée par le serveur » (leçon 26).

Le serveur fabrique alors le secret commun en deux parts (leçon 26). Pour la première, il crée sa paire X25519 et la combine avec la partie X25519 du client, comme à l'idée 5. Pour la seconde, il applique l'encapsulation à la clé publique ML-KEM du client. Il enferme un secret dans un colis : cela produit la seconde part et un bloc chiffré. Il renvoie sa clé publique X25519 et ce bloc, dans son key_share. Le client refait la première part, ouvre le bloc avec sa clé privée ML-KEM et obtient la seconde. Les deux côtés ont alors les mêmes deux parts, qui forment ensemble le secret commun. Le cours ne dit pas comment elles s'unissent.

7Une variable d'environnement donne à Wireshark les clés pour lire la capture

Ces 1216 octets, Clyde les lit dans Wireshark. Ce logiciel est gratuit (leçon 2). Il capture les paquets qui passent par votre carte réseau. En HTTPS, il ne voit que du charabia après le ServerHello : des coffres fermés qui défilent. Le navigateur, lui, garde en mémoire les clés de session, les clés de ces coffres. L'astuce : lui demander de les écrire dans un fichier (leçon 7). C'est la photocopie des clés qu'on confie à Wireshark.

On crée d'abord une variable d'environnement SSLKEYLOGFILE, un réglage nommé que les programmes lisent au démarrage et qui désigne ici un fichier texte. SSL est l'ancien nom de TLS, resté dans le nom (leçon 24). Clyde insiste sur l'orthographe : « Il faut l'écrire exactement comme ça » (leçon 7). On indique ensuite ce fichier dans les préférences de Wireshark (Edit, Preferences, Protocols, TLS).

Premier essai : Clyde a oublié de redémarrer le navigateur, et le fichier reste vide. Clyde ferme le navigateur, le rouvre et retourne sur google.com : cette fois, les clés s'écrivent (leçon 7). La capture montre alors le « 200 OK » et les en-têtes en clair. Le HTML, lui, reste illisible : sur HTTP/3, les données restent chiffrées malgré le fichier de clés, ce qui intrigue Clyde (leçon 7).

# exemple imaginé, pas du cours (qui le fait sous Windows)
export SSLKEYLOGFILE="$HOME/tls-keys.log"
firefox &    # lancé après la variable, sinon le fichier reste vide

Clyde prévient : « c'est assez dangereux si quelqu'un met la main sur ces clés de session » (leçon 27). Avec le fichier et une capture, on rouvre tous les coffres, y compris ceux d'hier : on relit les conversations passées. Mon conseil, qui n'est pas du cours : retirez la variable après usage.

8En local, vous devenez votre propre autorité de certification

La dernière partie du cours monte un HTTPS sur votre propre machine, nommée localhost, et Wireshark en prouve le résultat. Imaginez que vous créez votre propre autorité, la CA : elle vous remet un papier tamponné pour votre machine, et vous dites à votre ordinateur de croire cette autorité. Aucune CA publique ne signera pour localhost. Une CA vérifie que vous contrôlez le domaine, comme à l'idée 3, et personne d'autre ne voit votre machine (leçon 21). Tant que votre CA maison n'est pas dans le magasin de confiance, Chrome affiche « Votre connexion n'est pas privée » (leçon 32). Le cours refait donc la chaîne de confiance de l'idée 3 en miniature, avec XCA, un logiciel libre (leçons 29 à 32) :

1. Créer la CA « Wally Warthog Root CA » : clé RSA de 2048 bits, certificat de dix ans signé par elle-même (leçon 30).
2. Créer la clé et la CSR du serveur pour localhost. Le champ SAN (subject alternative name, les noms et adresses couverts) reçoit localhost et 127.0.0.1 (leçon 31).
3. Signer la CSR avec la CA, pour 365 jours (leçon 31).
4. Donner le certificat et la clé privée à Live Server, une extension de VS Code, sur le port 4430 (leçon 32). Ce port est 443, le port HTTPS habituel, avec un zéro ajouté pour l'essai en local.
5. Importer le certificat de la CA dans le magasin de confiance de Windows : votre ordinateur croit maintenant cette autorité, et l'avertissement disparaît (leçon 32).

Wireshark confirme : TLS 1.3 et un certificat de 1013 octets, visible grâce au fichier de clés, émis par « Wally Warthog Root CA ». Le HTML est lisible une fois déchiffré (leçon 33). Les valeurs 2048 bits, dix ans et 365 jours sont des choix pour un essai local. Le cours refait ensuite la recette avec OpenSSL, puis avec Node et le paquet npm mkcert. OpenSSL est une boîte à outils en ligne de commande.