Tu as l'adresse. Reste à frapper à la porte
À la leçon précédente, le DNS t'a donné l'IP de boutique.fr. Tu sais maintenant OÙ se trouve le serveur, son adresse exacte sur le réseau. Mais connaître une adresse ne suffit pas pour parler à quelqu'un. Il faut encore établir le contact, et le faire à l'abri des oreilles indiscrètes.
Cette leçon installe une idée qui va tout gouverner jusqu'à la fin du cours, et que tu dois graver dès maintenant : sur le réseau, ce qui coûte cher, ce n'est pas la taille de ce que tu envoies, c'est l'aller-retour. Pas le poids des données : le nombre de fois où un message doit traverser la planète et revenir. Garde cette phrase en tête, on va la chiffrer.
On va voir deux choses qui s'empilent : d'abord TCP, qui ouvre une connexion fiable. Ensuite TLS, qui pose un canal chiffré par-dessus. Et à chaque étape, on comptera les allers-retours.
TCP : décrocher le téléphone
Avant d'échanger quoi que ce soit d'utile, ton navigateur et le serveur doivent se mettre d'accord pour parler. C'est exactement comme un appel téléphonique : tu décroches, l'autre décroche, vous vous dites « allô, tu m'entends ? oui, je t'entends », et seulement là vous commencez la vraie conversation.
TCP fait pareil. On appelle ça le three-way handshake, la poignée de main en trois temps. Le détail technique a des noms (SYN, SYN-ACK, ACK), mais ne perds pas ton temps à les réciter pour briller. Le modèle à retenir tient en une phrase : se mettre d'accord pour parler coûte un aller-retour complet AVANT le premier octet utile. Un message part, une réponse revient, et c'est seulement après que la vraie discussion commence.
Pourquoi ce cérémonial ? Parce que TCP est fiable. Chaque morceau de données envoyé reçoit un accusé de réception ; si un bout se perd, il est renvoyé ; et si les morceaux arrivent dans le désordre, TCP les remet dans l'ordre avant de te les livrer. Tu as la garantie que rien ne manque et que tout arrive bien rangé.
L'autre approche existe : certains usages préfèrent UDP, la carte postale du réseau. On envoie le message d'un coup, sans poignée de main, sans accusé de réception : plus rapide, mais sans garantie que ça arrive ni dans quel ordre. On reparlera d'UDP à la dernière leçon : c'est sur lui que repose HTTP/3, qui ré-invente une connexion rapide là où TCP était devenu trop lent à démarrer.
Combien coûte un aller-retour ?
Mettons un chiffre sur cette histoire d'aller-retour. Entre Paris et New York, un message met environ 35 à 40 ms pour traverser l'Atlantique. Aller et revenir, c'est donc autour de 70 à 80 ms pour un seul aller-retour complet. Et c'est de la physique : la lumière dans une fibre ne va pas plus vite, aucune optimisation de code n'y changera rien.
Maintenant, empile. Une connexion sécurisée classique demande facilement trois allers-retours avant que le serveur ne t'envoie le premier octet de HTML : un pour TCP, un pour TLS, un pour la requête. Trois fois 70 ms, et tu dépasses déjà 200 ms d'attente avant la moindre ligne de page. Sur une page qui charge des dizaines de ressources, ça s'additionne vite.
Voilà LE problème. Et tout le reste du cours, ce sont des réponses à ce problème : le cache (leçon 7) évite carrément l'aller-retour, HTTP/2 et HTTP/3 (leçon 8) réduisent leur nombre. Tu comprends maintenant pourquoi : sur le web, on se bat contre l'aller-retour, pas contre la taille.
Le DNS est déjà résolu (tu as l'IP), et le serveur parle TLS 1.3. Entre l'instant où ta connexion démarre et l'instant où tu reçois le tout premier octet de HTML : combien d'allers-retours minimum vont s'écouler ?
Voir la réponse
Trois. Un pour le handshake TCP (se mettre d'accord pour parler). Un pour le handshake TLS 1.3 (établir le canal chiffré, et c'est bien un seul en 1.3, on le voit juste après). Et un pour la requête HTTP elle-même : tu demandes la page, le serveur répond. Soit, à 70 ms l'aller-retour, plus de 200 ms avant le premier octet. Sans cache ni reprise de connexion, on ne descend pas en dessous.
TLS : poser un canal chiffré par-dessus
TCP a ouvert une connexion fiable, mais elle est en clair : n'importe qui sur le chemin (le Wi-Fi du café, ton fournisseur d'accès) pourrait lire ce qui passe. TLS vient régler ça. C'est la couche qui transforme le http:// en https:// : un canal chiffré posé par-dessus la connexion TCP existante.
Pour établir ce canal, client et serveur jouent un petit dialogue, le handshake TLS, en quatre temps :
- Le client se présente. Ton navigateur dit « bonjour, voici les méthodes de chiffrement que je sais utiliser ».
- Le serveur répond et montre son certificat. C'est sa pièce d'identité : un document signé par une autorité de certification que ton navigateur connaît déjà et en qui il a confiance. C'est ça qui prouve que tu parles bien à
boutique.fr, et pas à un imposteur. - Ils fabriquent ensemble une clé de session. À partir de leur échange, les deux camps calculent une clé secrète que personne d'autre sur le réseau ne connaît, pas même quelqu'un qui aurait tout écouté.
- Tout ce qui suit est chiffré. À partir de là, chaque octet qui transite est brouillé avec cette clé. Un espion ne voit plus que du bruit.
Le gain de TLS 1.3 : ce handshake en quatre temps tient désormais en un seul aller-retour. C'est la grande amélioration de TLS 1.3 par rapport à TLS 1.2, qui en demandait deux. Concrètement, sur une connexion neuve, TLS 1.3 te fait gagner un aller-retour complet, soit ~70 ms d'attente en moins avant la première donnée. Quand tu choisis un hébergeur ou une config, exiger TLS 1.3 n'est pas un détail de sécurité : c'est aussi de la vitesse.
Le handshake, étape par étape
Ouvre chaque étape pour voir ce qui se dit et, surtout, ce qui transite sur le réseau à ce moment précis. C'est le même dialogue que ci-dessus, mais déroulé comme tu pourrais l'observer en direct.
1 Le client dit bonjour client → serveur
Ton navigateur ouvre la discussion. Il annonce la version de TLS qu'il veut utiliser et la liste des méthodes de chiffrement qu'il sait gérer.
Ce qui transite : un message « bonjour » en clair (le chiffrement n'est pas encore en place), avec le nom du site visé et les options proposées. Rien de secret ici, juste une mise en relation.
2 Le serveur répond et montre sa carte d'identité serveur → client
Le serveur choisit une méthode parmi celles proposées, puis présente son certificat.
Ce qui transite : le certificat du serveur, signé par une autorité que ton navigateur connaît. Le navigateur vérifie cette signature tout seul : si elle ne colle pas, ou si le certificat n'est pas pour boutique.fr, il affiche l'écran rouge d'alerte et refuse de continuer.
3 Ils fabriquent une clé secrète commune les deux côtés
À partir des éléments échangés, chaque camp calcule de son côté la même clé de session, sans jamais la transmettre en entier sur le réseau.
Ce qui transite : juste assez d'informations pour que les deux arrivent au même secret, mais pas la clé elle-même. Un espion qui aurait tout enregistré ne peut pas la reconstituer.
4 Le canal est chiffré à partir de maintenant
La poignée de main est finie. Tout ce qui passe désormais, à commencer par ta requête HTTP, est brouillé avec la clé de session.
Ce qui transite : uniquement des données chiffrées. L'observateur du réseau voit qu'une connexion existe vers boutique.fr, mais ne lit ni ta requête, ni la page, ni ton mot de passe.
La séquence complète, allers-retours comptés
Voici tout ce qui se passe AVANT le premier octet de HTML, dessiné. Compte les flèches qui partent et reviennent : trois allers-retours, et seulement après, la page commence à arriver.
Le cadenas ne dit PAS ce que tu crois
C'est l'erreur la plus répandue sur HTTPS, et elle peut coûter cher. Mettons-la à plat.
« Le cadenas, donc le site est honnête » : faux. TLS fait deux choses, et deux seulement : il chiffre le canal (personne ne lit ce qui passe entre toi et le serveur) et il authentifie le serveur (tu parles bien à la machine qui contrôle boutique.fr). C'est tout. Il ne dit rien de l'honnêteté du site lui-même. Un site de phishing peut très bien afficher un beau cadenas vert : il a juste un certificat valide pour son propre domaine d'arnaque. Le cadenas garantit « personne n'écoute notre conversation », pas « tu peux faire confiance à cette boutique ».
Même famille d'illusion : « le cadenas, donc tout est sûr ». Non. Le cadenas couvre le transport. Ce que le site fait de tes données une fois reçues, s'il les stocke n'importe comment, s'il revend ton email, le cadenas n'en sait rien et ne te protège de rien. La sécurité du canal et la confiance dans le site sont deux questions séparées.
Et ce fameux certificat, on le trouve où ?
Tu te demandes peut-être comment un serveur obtient cette pièce d'identité signée. Bonne nouvelle : c'est gratuit aujourd'hui. Le cours Déploiement (HTTPS avec Caddy) montre exactement comment décrocher un certificat valide en quelques secondes grâce à Let's Encrypt, et le renouveler tout seul. La théorie que tu viens de lire devient là-bas un vrai serveur qui sert du https://.
You have the address. Now knock on the door
In the previous lesson, DNS handed you the IP of boutique.fr. You now know WHERE the server is, its exact address on the network. But knowing an address isn't enough to talk to someone. You still have to make contact, and do it out of earshot of eavesdroppers.
This lesson plants an idea that will govern everything until the end of the course, and that you should carve in now: on the network, what costs you isn't the size of what you send, it's the round trip. Not the weight of the data: the number of times a message has to cross the planet and come back. Keep that sentence in mind — we're about to put numbers on it.
We'll see two things stacked on top of each other: first TCP, which opens a reliable connection. Then TLS, which lays an encrypted channel over it. And at every step, we'll count the round trips.
TCP: picking up the phone
Before exchanging anything useful, your browser and the server have to agree to talk. It's exactly like a phone call: you pick up, the other picks up, you say "hello, can you hear me? — yes, I hear you", and only then does the real conversation start.
TCP does the same. It's called the three-way handshake. The technical detail has names (SYN, SYN-ACK, ACK), but don't waste your time reciting them to show off. The model to keep fits in one sentence: agreeing to talk costs one full round trip BEFORE the first useful byte. A message goes out, a reply comes back, and only after that does the real discussion begin.
Why this ceremony? Because TCP is reliable. Every chunk of data sent gets an acknowledgement; if a piece is lost, it's resent; and if pieces arrive out of order, TCP reorders them before handing them to you. You're guaranteed nothing is missing and everything arrives neatly arranged.
The other approach exists: some uses prefer UDP, the network's postcard. You fire off the message in one go, no handshake, no acknowledgement: faster, but with no guarantee it arrives or in what order. We'll come back to UDP in the last lesson: it's what HTTP/3 is built on, reinventing a fast connection where TCP had become too slow to start.
How much does a round trip cost?
Let's put a number on this round-trip business. Between Paris and New York, a message takes about 35 to 40 ms to cross the Atlantic. There and back is therefore around 70 to 80 ms for a single full round trip. And it's physics: light in a fibre doesn't go faster, no code optimisation will change it.
Now stack them. A classic secure connection easily needs three round trips before the server sends you the first byte of HTML: one for TCP, one for TLS, one for the request. Three times 70 ms, and you already pass 200 ms of waiting before a single line of page. On a page loading dozens of resources, it adds up fast.
That's THE problem. And the whole rest of the course is answers to it: caching (lesson 7) avoids the round trip entirely, HTTP/2 and HTTP/3 (lesson 8) cut their number. Now you see why: on the web, you fight the round trip, not the size.
DNS is already resolved (you have the IP), and the server speaks TLS 1.3. Between the moment your connection starts and the moment you get the very first byte of HTML: how many round trips minimum will pass?
Show the answer
Three. One for the TCP handshake (agreeing to talk). One for the TLS 1.3 handshake (setting up the encrypted channel — and yes, just one in 1.3, we'll see it right after). And one for the HTTP request itself: you ask for the page, the server replies. So, at 70 ms per round trip, over 200 ms before the first byte. Without caching or connection resumption, you can't go below that.
TLS: laying an encrypted channel over it
TCP opened a reliable connection, but it's in the clear: anyone on the path (the café Wi-Fi, your ISP) could read what goes by. TLS fixes that. It's the layer that turns http:// into https://: an encrypted channel laid on top of the existing TCP connection.
To set up this channel, client and server play a short dialogue, the TLS handshake, in four beats:
- The client introduces itself. Your browser says "hello, here are the encryption methods I know how to use".
- The server replies and shows its certificate. That's its ID: a document signed by a certificate authority your browser already knows and trusts. That's what proves you're really talking to
boutique.fr, and not an impostor. - Together they build a session key. From their exchange, both sides compute a secret key that no one else on the network knows, not even someone who listened to everything.
- Everything after is encrypted. From here, every byte that travels is scrambled with that key. A spy sees nothing but noise.
The TLS 1.3 win: this four-beat handshake now fits in a single round trip. That's the big improvement of TLS 1.3 over TLS 1.2, which needed two. Concretely, on a fresh connection, TLS 1.3 saves you a full round trip — about 70 ms of waiting cut before the first data. When you pick a host or a config, demanding TLS 1.3 isn't just a security detail: it's speed too.
The handshake, step by step
Open each step to see what's said and, above all, what travels on the network at that precise moment. It's the same dialogue as above, but unrolled as you might watch it live.
1 The client says hello client → server
Your browser opens the discussion. It announces the TLS version it wants to use and the list of encryption methods it can handle.
What travels: a "hello" message in the clear (encryption isn't set up yet), with the name of the target site and the proposed options. Nothing secret here, just a first connection.
2 The server replies and shows its ID server → client
The server picks a method from those offered, then presents its certificate.
What travels: the server's certificate, signed by an authority your browser knows. The browser checks that signature on its own: if it doesn't match, or if the certificate isn't for boutique.fr, it shows the red warning screen and refuses to go on.
3 They build a shared secret key both sides
From the exchanged elements, each side computes the same session key on its own, without ever sending it whole over the network.
What travels: just enough information for both to reach the same secret, but not the key itself. A spy who recorded everything cannot reconstruct it.
4 The channel is encrypted from now on
The handshake is over. Everything that passes from now on, starting with your HTTP request, is scrambled with the session key.
What travels: only encrypted data. A network observer sees that a connection to boutique.fr exists, but reads neither your request, nor the page, nor your password.
The full sequence, round trips counted
Here is everything that happens BEFORE the first byte of HTML, drawn. Count the arrows that go and come back: three round trips, and only then does the page start arriving.
The padlock does NOT mean what you think
This is the most widespread mistake about HTTPS, and it can cost you. Let's lay it out flat.
"Padlock, so the site is honest": false. TLS does two things, and only two: it encrypts the channel (no one reads what passes between you and the server) and it authenticates the server (you're really talking to the machine that controls boutique.fr). That's all. It says nothing about the site's own honesty. A phishing site can perfectly well display a nice green padlock: it just has a valid certificate for its own scam domain. The padlock guarantees "no one is listening to our conversation", not "you can trust this shop".
Same family of illusion: "padlock, so everything is safe". No. The padlock covers transport. What the site does with your data once received, whether it stores it carelessly, whether it sells your email, the padlock knows nothing about and protects you from nothing. Channel security and trust in the site are two separate questions.
And that famous certificate, where do you get it?
You might wonder how a server gets this signed ID. Good news: it's free today. The Deployment course (HTTPS with Caddy) shows exactly how to grab a valid certificate in seconds thanks to Let's Encrypt, and renew it automatically. The theory you just read becomes, over there, a real server serving https://.
🎯 Pratique
S'entraîner (clique pour ouvrir) :
💬 Ré-explique sans regarder
Explique à un ami pourquoi ouvrir une page en HTTPS coûte du temps AVANT même le premier octet de HTML, en parlant d'allers-retours et de ce que fait TLS.
🧠 Rappel libre
Sans remonter : quelles sont les deux choses, et seulement deux, que TLS garantit ? Et qu'est-ce qu'il ne garantit PAS ?
⚖️ Juge le conseil de l'IA
Tu demandes à l'IA si un site est fiable pour y saisir ta carte bancaire. Elle répond : « Le site affiche un cadenas vert, le certificat est valide : tu peux y entrer tes coordonnées bancaires en toute confiance. » Tu acceptes ce raisonnement, ou tu le rejettes ?
Le canal est ouvert et chiffré : personne n'écoute, et tu sais à qui tu parles. Enfin, on parle ! Leçon 5 : la lettre elle-même. Les méthodes (GET, POST...), les en-têtes, et surtout les codes de statut que tu liras toute ta vie de dev : 200, 301, 404, 500. Apprends à les lire une bonne fois.
Leçon 5 : Requête, réponse, status codes →