Module 15 – BONUS : Le Handshake TCP et TLS expliqué simplement
+==============================================================================+
| MODULE 15 (BONUS) : HANDSHAKE TCP + TLS (HTTPS) |
| Durée estimée: 1 heure | Niveau: Débutant absolu |
+==============================================================================+
Table des matières
- Pourquoi cette page ?
- Le vocabulaire de base – Les « drapeaux » TCP
- Le handshake TCP en 3 étapes (SYN / SYN-ACK / ACK)
- Et après le handshake ? Les échanges de données (PSH, ACK)
- Comment on ferme la connexion ? (FIN / FIN-ACK)
- Récapitulatif complet d'une connexion TCP
- Le handshake TLS – Ajouter le cadenas
- Exemple concret : Ouvrir https://google.com
- Ce que tu vois dans Wireshark
- Résumé final – L'analogie complète
Pourquoi cette page ?
Quand tu ouvres un site web, ton navigateur et le serveur se parlent. Mais avant de s'échanger quoi que ce soit, ils doivent :
- Vérifier qu'ils peuvent se parler (handshake TCP)
- Se mettre d'accord sur comment chiffrer (handshake TLS, si HTTPS)
- Échanger les données (la page web)
- Raccrocher proprement (fermeture de connexion)
Tous ces échanges utilisent des petits drapeaux (flags) dans les paquets réseau. C'est ce qu'on va expliquer ici, comme si tu n'avais jamais fait de réseau.
Retour à la table des matières
Le vocabulaire de base – Les « drapeaux » TCP
Imagine que chaque message réseau est une lettre envoyée par la poste. Sur chaque enveloppe, il y a un ou plusieurs tampons (drapeaux) qui disent quel type de message c'est.
Voici les principaux drapeaux TCP :
| Drapeau | Nom complet | Analogie simple | Signification technique |
|---|---|---|---|
| SYN | Synchronize | 📞 « Allô ? Tu es là ? » | « Je veux ouvrir une connexion » |
| ACK | Acknowledge | ✅ « Bien reçu ! » | « J'ai bien reçu ton message » |
| PSH | Push | 📦 « Voilà le colis, ouvre-le tout de suite ! » | « Voici des données, traite-les immédiatement » |
| FIN | Finish | 👋 « Au revoir, je raccroche » | « Je veux fermer la connexion » |
| RST | Reset | ❌ « STOP ! Raccroché de force ! » | « Connexion annulée / refusée brutalement » |
Le plus important à retenir
- SYN = « je veux commencer »
- ACK = « j'ai compris / bien reçu »
- PSH = « voilà les vraies données »
- FIN = « j'ai fini, au revoir »
Retour à la table des matières
Le handshake TCP en 3 étapes (SYN / SYN-ACK / ACK)
L'analogie du téléphone
Imagine que tu appelles un ami :
┌─────────────────────────────────────────────────────────────────────┐
│ APPEL TÉLÉPHONIQUE │
│ │
│ Toi (Client) Ton ami (Serveur) │
│ │
│ 1. 📞 « Allô ? Tu m'entends ? » ──────► │
│ (Le téléphone sonne) │
│ │
│ ◄────── 2. 📞 « Oui, je t'entends ! │
│ Et toi, tu m'entends ? » │
│ │
│ 3. 📞 « Oui parfait, on peut parler ! » ──────► │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ ✅ CONVERSATION ÉTABLIE — Vous pouvez discuter ! │
└─────────────────────────────────────────────────────────────────────┘
La même chose en TCP
┌─────────────────────────────────────────────────────────────────────┐
│ HANDSHAKE TCP (3-WAY HANDSHAKE) │
│ │
│ Client (ton PC) Serveur (ex: google.com) │
│ │
│ ÉTAPE 1 : SYN │
│ ──────────────────────────────────────► │
│ « Je veux me connecter. Mon numéro │
│ de séquence de départ est 100. » │
│ │
│ ÉTAPE 2 : SYN-ACK │
│ ◄────────────────────────────────────── │
│ « OK, j'accepte (ACK ton 100). │
│ Mon numéro de séquence est 300. » │
│ │
│ ÉTAPE 3 : ACK │
│ ──────────────────────────────────────► │
│ « Parfait, bien reçu (ACK ton 300). │
│ On peut commencer ! » │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ ✅ CONNEXION TCP ÉTABLIE │
│ ❌ Mais RIEN n'est chiffré pour l'instant ! │
└─────────────────────────────────────────────────────────────────────┘
Pourquoi 3 étapes et pas 1 ?
C'est pour vérifier que la communication fonctionne dans les deux sens :
| Étape | Prouve que... |
|---|---|
| SYN (Client → Serveur) | Le client peut envoyer au serveur |
| SYN-ACK (Serveur → Client) | Le serveur a reçu ET peut répondre |
| ACK (Client → Serveur) | Le client a reçu la réponse du serveur |
Sans ces 3 étapes, on ne saurait pas si les deux machines se comprennent vraiment.
Retour à la table des matières
Et après le handshake ? Les échanges de données (PSH, ACK)
Une fois la connexion ouverte, les vraies données circulent. C'est là qu'on voit PSH et ACK :
L'analogie de la livraison de colis
┌─────────────────────────────────────────────────────────────────────┐
│ ÉCHANGE DE DONNÉES (après le handshake) │
│ │
│ Client (navigateur) Serveur (site web) │
│ │
│ 📦 PSH,ACK : « Voilà ma demande : │
│ je veux la page d'accueil » ──────────────► │
│ (= requête HTTP GET /) │
│ │
│ ◄────────────── ✅ ACK : │
│ « Bien reçu ta demande » │
│ │
│ ◄────────────── 📦 PSH,ACK : │
│ « Voilà la page HTML ! » │
│ (= réponse HTTP 200 OK) │
│ │
│ ✅ ACK : « Bien reçu la page, │
│ merci ! » ──────────────► │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ 📄 La page s'affiche dans ton navigateur ! │
└─────────────────────────────────────────────────────────────────────┘
Pourquoi PSH + ACK ensemble ?
Tu verras souvent PSH,ACK dans Wireshark (les deux drapeaux en même temps). C'est normal :
| Drapeau | Rôle dans ce paquet |
|---|---|
| PSH | « Voici des données, traite-les tout de suite » |
| ACK | « Au passage, j'ai bien reçu tes messages précédents » |
PSH = « J'envoie un colis »
ACK = « Et j'accuse réception de ce que tu m'as envoyé avant »
Les deux ensemble = efficacité : on fait deux choses en un seul paquet !
Et si on ne met pas PSH ?
Sans PSH, les données arrivent mais le système pourrait attendre avant de les traiter (il les met en "tampon"/buffer). Avec PSH, c'est « traite ça immédiatement ! ».
Pense à la différence entre :
- 📬 Mettre une lettre dans la boîte aux lettres (sans PSH → le facteur traitera quand il voudra)
- 🚨 Sonner à la porte et dire « c'est urgent, lis tout de suite ! » (avec PSH)
Retour à la table des matières
Comment on ferme la connexion ? (FIN / FIN-ACK)
Quand la conversation est terminée, on raccroche proprement :
┌─────────────────────────────────────────────────────────────────────┐
│ FERMETURE DE CONNEXION (4-WAY) │
│ │
│ Client Serveur │
│ │
│ 👋 FIN,ACK : « J'ai fini, │
│ je veux raccrocher » ──────────────► │
│ │
│ ◄────────────── ✅ ACK : │
│ « OK, j'ai compris » │
│ │
│ ◄────────────── 👋 FIN,ACK : │
│ « Moi aussi j'ai fini » │
│ │
│ ✅ ACK : « OK, au revoir ! » ──────────────► │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ 🔌 CONNEXION FERMÉE PROPREMENT │
└─────────────────────────────────────────────────────────────────────┘
Et RST dans tout ça ?
RST (Reset), c'est quand on raccroche brutalement, sans dire au revoir :
| Situation | Ce qui se passe |
|---|---|
| Le port est fermé sur le serveur | Le serveur répond RST → « Ce service n'existe pas ! » |
| Le pare-feu bloque la connexion | Soit RST, soit pas de réponse du tout (timeout) |
| L'application plante | Le système envoie RST pour couper la connexion |
FIN = raccrocher poliment 👋
RST = claquer le téléphone au visage ❌
Retour à la table des matières
Récapitulatif complet d'une connexion TCP
Voici tout le cycle de vie d'une connexion TCP, du début à la fin :
┌─────────────────────────────────────────────────────────────────────┐
│ CYCLE DE VIE COMPLET D'UNE CONNEXION TCP │
│ │
│ ╔═══════════════════════════════════════════════════════════╗ │
│ ║ PHASE 1 : OUVERTURE (3-way handshake) ║ │
│ ║ ║ │
│ ║ Client ──── SYN ────────► Serveur ║ │
│ ║ Client ◄─── SYN,ACK ──── Serveur ║ │
│ ║ Client ──── ACK ────────► Serveur ║ │
│ ╚═══════════════════════════════════════════════════════════╝ │
│ │ │
│ ▼ │
│ ╔═══════════════════════════════════════════════════════════╗ │
│ ║ PHASE 2 : ÉCHANGE DE DONNÉES ║ │
│ ║ ║ │
│ ║ Client ──── PSH,ACK ───► Serveur (requête) ║ │
│ ║ Client ◄─── ACK ──────── Serveur (accusé réception) ║ │
│ ║ Client ◄─── PSH,ACK ──── Serveur (réponse) ║ │
│ ║ Client ──── ACK ────────► Serveur (accusé réception) ║ │
│ ╚═══════════════════════════════════════════════════════════╝ │
│ │ │
│ ▼ │
│ ╔═══════════════════════════════════════════════════════════╗ │
│ ║ PHASE 3 : FERMETURE (4-way) ║ │
│ ║ ║ │
│ ║ Client ──── FIN,ACK ───► Serveur ║ │
│ ║ Client ◄─── ACK ──────── Serveur ║ │
│ ║ Client ◄─── FIN,ACK ──── Serveur ║ │
│ ║ Client ──── ACK ────────► Serveur ║ │
│ ╚═══════════════════════════════════════════════════════════╝ │
│ │
│ 🏁 FIN — Connexion terminée proprement │
└─────────────────────────────────────────────────────────────────────┘
Retour à la table des matières
Le handshake TLS – Ajouter le cadenas
Quand est-ce que TLS intervient ?
TLS se place entre le handshake TCP et les données :
Étape 1 : Handshake TCP → « On ouvre la porte »
Étape 2 : Handshake TLS → « On met le cadenas + on vérifie l'identité »
Étape 3 : Données chiffrées → « On parle, mais personne ne peut écouter »
L'analogie de la banque
Imagine que tu veux envoyer un message secret à ta banque :
┌─────────────────────────────────────────────────────────────────────┐
│ HANDSHAKE TLS (simplifié) │
│ │
│ Toi (Client) La Banque (Serveur) │
│ │
│ ÉTAPE 1 — ClientHello │
│ ──────────────────────────────────────► │
│ « Bonjour ! Je voudrais communiquer en secret. │
│ Voilà les méthodes de chiffrement que je connais : │
│ AES-256, ChaCha20, etc. » │
│ │
│ ÉTAPE 2 — ServerHello + Certificat │
│ ◄────────────────────────────────────── │
│ « OK ! On va utiliser AES-256. │
│ Et voici ma CARTE D'IDENTITÉ (certificat) : │
│ - Je suis bien "Banque Nationale" │
│ - Signé par une autorité de confiance (Let's Encrypt, etc.) │
│ - Valide jusqu'au 2026-12-31 » │
│ │
│ ÉTAPE 3 — Vérification (côté client) │
│ 🔍 Tu vérifies la carte d'identité : │
│ ✅ Le nom correspond au site ? │
│ ✅ Signé par une autorité reconnue ? │
│ ✅ Pas expiré ? │
│ → Si tout est OK, on continue. Sinon = erreur de certificat. │
│ │
│ ÉTAPE 4 — Échange de clés │
│ ──────────────────────────────────────► │
│ 🔐 Le client et le serveur se mettent d'accord sur un │
│ SECRET PARTAGÉ (sans jamais l'envoyer en clair !) │
│ Méthode : Diffie-Hellman ou similaire. │
│ │
│ Analogie : imagine que vous mélangez chacun une couleur │
│ de peinture en secret. Vous échangez le résultat, │
│ et vous arrivez tous les deux à la MÊME couleur finale, │
│ mais quelqu'un qui observe ne peut PAS la deviner. │
│ │
│ ÉTAPE 5 — Finished │
│ ◄─────────── (les deux côtés) ──────────► │
│ « On a les mêmes clés secrètes. │
│ À partir de maintenant, TOUT est chiffré ! » │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ 🔒 TUNNEL TLS ÉTABLI — Toute la communication est chiffrée ! │
└─────────────────────────────────────────────────────────────────────┘
Les questions fréquentes
C'est quoi un certificat ?
C'est la carte d'identité numérique du serveur. Elle contient :
- Le nom du site (ex:
google.com) - La clé publique du serveur
- La signature d'une autorité de certification (ex: Let's Encrypt, DigiCert)
- La date d'expiration
Ton navigateur vérifie tout ça automatiquement. Si quelque chose ne colle pas → 🔴 « Votre connexion n'est pas privée ».
C'est quoi Diffie-Hellman ?
C'est une méthode mathématique pour que deux personnes se mettent d'accord sur un secret commun, même si quelqu'un écoute tous leurs messages.
Analogie des couleurs de peinture :
Toi : choisis secrètement du BLEU 🔵
Banque : choisit secrètement du ROUGE 🔴
Couleur de base publique : JAUNE 🟡
Toi : mélanges JAUNE + BLEU = VERT 🟢 → tu envoies le VERT
Banque : mélange JAUNE + ROUGE = ORANGE 🟠 → elle envoie l'ORANGE
Toi : reçois ORANGE + ton BLEU secret = MARRON 🟤
Banque : reçoit VERT + son ROUGE secret = MARRON 🟤
✅ Vous avez la même couleur finale (MARRON) !
❌ L'espion ne voit que VERT et ORANGE... il ne peut PAS trouver MARRON !
En vrai, ce ne sont pas des couleurs mais des gros nombres mathématiques, mais le principe est identique.
Retour à la table des matières
Exemple concret : Ouvrir https://google.com
Voici ce qui se passe réellement quand tu tapes https://google.com dans ton navigateur :
┌─────────────────────────────────────────────────────────────────────┐
│ TON PC (192.168.1.50) GOOGLE (142.250.80.46) │
│ │
│ ── ÉTAPE 1 : RÉSOLUTION DNS ────────────────────────────────── │
│ « C'est quoi l'IP de google.com ? » │
│ → Réponse DNS : 142.250.80.46 │
│ │
│ ── ÉTAPE 2 : HANDSHAKE TCP ─────────────────────────────────── │
│ Paquet 1: [SYN] 192.168.1.50:54321 → 142.250.80.46:443 │
│ Paquet 2: [SYN,ACK] 142.250.80.46:443 → 192.168.1.50:54321 │
│ Paquet 3: [ACK] 192.168.1.50:54321 → 142.250.80.46:443 │
│ ✅ Connexion TCP établie sur le port 443 (HTTPS) │
│ │
│ ── ÉTAPE 3 : HANDSHAKE TLS ─────────────────────────────────── │
│ Paquet 4: ClientHello → versions TLS, algorithmes proposés │
│ Paquet 5: ServerHello ← algorithme choisi │
│ Paquet 6: Certificate ← certificat de google.com │
│ Paquet 7: Key Exchange ↔ échange Diffie-Hellman │
│ Paquet 8: Finished ↔ vérification des deux côtés │
│ 🔒 Tunnel TLS établi — tout est chiffré maintenant │
│ │
│ ── ÉTAPE 4 : DONNÉES CHIFFRÉES ─────────────────────────────── │
│ Paquet 9: [PSH,ACK] (chiffré) → GET / HTTP/1.1 │
│ (ta requête pour la page d'accueil) │
│ Paquet 10: [ACK] ← accusé de réception │
│ Paquet 11: [PSH,ACK] (chiffré) ← HTTP/1.1 200 OK + page HTML │
│ (la page d'accueil de Google) │
│ Paquet 12: [ACK] → accusé de réception │
│ 📄 La page Google s'affiche dans ton navigateur ! │
│ │
│ ── ÉTAPE 5 : FERMETURE ─────────────────────────────────────── │
│ Paquet 13: [FIN,ACK] → « J'ai fini » │
│ Paquet 14: [FIN,ACK] ← « Moi aussi » │
│ Paquet 15: [ACK] → « OK, au revoir » │
│ 🔌 Connexion fermée │
└─────────────────────────────────────────────────────────────────────┘
Port 443 vs Port 80
- Port 80 = HTTP (pas chiffré) → pas de handshake TLS
- Port 443 = HTTPS (chiffré) → handshake TLS obligatoire
C'est pour ça que l'URL https:// utilise toujours le port 443 par défaut.
Retour à la table des matières
Ce que tu vois dans Wireshark
Capture HTTP (port 80) – PAS chiffré
┌──────┬────────────────────┬────────────────────┬──────────┬──────────────────────┐
│ No │ Source │ Destination │ Protocol │ Info │
├──────┼────────────────────┼────────────────────┼──────────┼──────────────────────┤
│ 1 │ 192.168.1.50 │ 93.184.216.34 │ TCP │ SYN │
│ 2 │ 93.184.216.34 │ 192.168.1.50 │ TCP │ SYN, ACK │
│ 3 │ 192.168.1.50 │ 93.184.216.34 │ TCP │ ACK │
│ 4 │ 192.168.1.50 │ 93.184.216.34 │ HTTP │ GET / HTTP/1.1 ⚠️ │
│ 5 │ 93.184.216.34 │ 192.168.1.50 │ TCP │ ACK │
│ 6 │ 93.184.216.34 │ 192.168.1.50 │ HTTP │ 200 OK ⚠️ │
└──────┴────────────────────┴────────────────────┴──────────┴──────────────────────┘
⚠️ On voit TOUT en clair ! La requête, la réponse, le contenu de la page...
N'importe qui sur le réseau peut lire ces données !
Capture HTTPS (port 443) – Chiffré
┌──────┬────────────────────┬────────────────────┬──────────┬──────────────────────┐
│ No │ Source │ Destination │ Protocol │ Info │
├──────┼────────────────────┼────────────────────┼──────────┼──────────────────────┤
│ 1 │ 192.168.1.50 │ 142.250.80.46 │ TCP │ SYN │
│ 2 │ 142.250.80.46 │ 192.168.1.50 │ TCP │ SYN, ACK │
│ 3 │ 192.168.1.50 │ 142.250.80.46 │ TCP │ ACK │
│ 4 │ 192.168.1.50 │ 142.250.80.46 │ TLSv1.3 │ Client Hello │
│ 5 │ 142.250.80.46 │ 192.168.1.50 │ TLSv1.3 │ Server Hello │
│ 6 │ 142.250.80.46 │ 192.168.1.50 │ TLSv1.3 │ Certificate │
│ 7 │ 192.168.1.50 │ 142.250.80.46 │ TLSv1.3 │ Key Exchange │
│ 8 │ ... │ ... │ TLSv1.3 │ Finished │
│ 9 │ 192.168.1.50 │ 142.250.80.46 │ TLSv1.3 │ Application Data 🔒 │
│ 10 │ 142.250.80.46 │ 192.168.1.50 │ TLSv1.3 │ Application Data 🔒 │
└──────┴────────────────────┴────────────────────┴──────────┴──────────────────────┘
🔒 "Application Data" = données chiffrées. On ne peut PAS lire le contenu !
On voit juste qu'il y a du trafic, mais pas CE QUI est échangé.
Ce qu'un attaquant peut voir en HTTPS
Même avec HTTPS, un attaquant sur le réseau peut voir :
- L'adresse IP du serveur (ex: 142.250.80.46)
- Le nom du site (via le champ SNI dans ClientHello, ex:
google.com) - La quantité de données échangées
- Le moment de la connexion
Mais il ne peut PAS voir :
- ❌ L'URL complète (ex:
/search?q=mon+secret) - ❌ Le contenu de la page
- ❌ Les cookies, mots de passe, formulaires
- ❌ Les données envoyées dans les deux sens
Retour à la table des matières
Résumé final – L'analogie complète
HTTP vs HTTPS en une image
┌─────────────────────────────────────────────────────────────────────┐
│ │
│ HTTP (port 80) HTTPS (port 443) │
│ │
│ 📞 Handshake TCP 📞 Handshake TCP │
│ (SYN → SYN,ACK → ACK) (SYN → SYN,ACK → ACK) │
│ │ │ │
│ │ 🔒 Handshake TLS │
│ │ (ClientHello → Certificate → Keys) │
│ │ │ │
│ ▼ ▼ │
│ 📦 Données EN CLAIR 📦 Données CHIFFRÉES │
│ (tout le monde peut lire) (personne ne peut lire) │
│ │ │ │
│ 👋 Fermeture TCP 👋 Fermeture TCP │
│ (FIN → ACK) (FIN → ACK) │
│ │
│ 🔴 Dangereux ! 🟢 Sécurisé ! │
└─────────────────────────────────────────────────────────────────────┘
Le mémo des drapeaux TCP
┌──────────────────────────────────────────────────────────────────┐
│ MÉMO DES DRAPEAUX TCP │
│ │
│ SYN = 📞 « Je veux ouvrir une connexion » │
│ ACK = ✅ « Bien reçu ! » │
│ PSH = 📦 « Voilà des données, traite-les tout de suite » │
│ FIN = 👋 « J'ai fini, au revoir » │
│ RST = ❌ « Raccroché de force ! » │
│ │
│ SYN,ACK = 📞✅ « J'accepte ta connexion + bien reçu » │
│ PSH,ACK = 📦✅ « Voilà des données + j'ai reçu les tiennes »│
│ FIN,ACK = 👋✅ « Je ferme + j'ai reçu tes derniers messages »│
└──────────────────────────────────────────────────────────────────┘
Le résumé en 5 phrases
Résumé
- TCP ouvre la connexion avec SYN / SYN-ACK / ACK (3-way handshake)
- TLS sécurise la connexion avec certificat + échange de clés (handshake TLS)
- PSH,ACK envoie les vraies données (requêtes HTTP, pages web, etc.)
- FIN,ACK ferme proprement la connexion
- ACK accompagne presque tout : c'est juste un « bien reçu » qui permet de ne rien perdre
Retour à la table des matières
TP Bonus créé le : Février 2026