Décrire les 3 étapes du TCP 3-Way Handshake avec les numéros de séquence
Comprendre les états TCP (SYN_SENT, ESTABLISHED, FIN_WAIT, CLOSE_WAIT…)
Identifier les failles de sécurité liées au handshake (SYN flood, session hijacking)
1
Simulateur : ouverture et fermeture d'une connexion TCP
Naviguez étape par étape pour observer les drapeaux échangés entre client et serveur, et les états TCP associés en temps réel.
💻
Client
192.168.1.10
CLOSED
SYN▶
① SYN : Client choisit Seq=1000. Envoie SYN : « Je veux me connecter. » État client : SYN_SENT.
◀SYN-ACK
② SYN-ACK : Serveur accuse réception (Ack=1001) et propose son Seq=5000. État serveur : SYN_RECEIVED.
ACK▶
③ ACK : Client confirme (Ack=5001). Les deux passent à ESTABLISHED. Transfert de données possible.
🖥️
Serveur
93.184.216.34
LISTEN
LISTEN
SYN_SENT
SYN_RECEIVED
ESTABLISHED
Étape 0/3 : Connexion fermée
💻
Client
192.168.1.10
ESTABLISHED
FIN▶
① FIN : Client n'a plus de données à envoyer. État client : FIN_WAIT_1.
◀ACK
② ACK : Serveur accuse réception. Client : FIN_WAIT_2. Serveur peut encore envoyer des données.
◀FIN
③ FIN : Serveur a terminé d'envoyer. État serveur : LAST_ACK.
ACK▶
④ ACK : Client confirme. Il entre en TIME_WAIT (2×MSL ≈ 2 min), puis CLOSED. Serveur passe directement à CLOSED.
🖥️
Serveur
93.184.216.34
ESTABLISHED
ESTABLISHED
FIN_WAIT_1
FIN_WAIT_2
LAST_ACK
TIME_WAIT
CLOSED
Étape 0/4 : Connexion active
Pourquoi 3-Way pour ouvrir, 4-Way pour fermer ? L'ouverture synchronise deux séquences en 3 messages (SYN, SYN+ACK, ACK). La fermeture est asymétrique : chaque côté ferme sa direction indépendamment (half-close), d'où 4 messages séparés.
2
La machine à états TCP
TCP définit 11 états standardisés (RFC 793). Voici les deux chemins principaux : côté client (actif) et côté serveur (passif).
💻 Côté client (ouverture active)
CLOSED↓ active open / SYN
SYN_SENT↓ reçoit SYN-ACK
ESTABLISHED↓ envoie FIN
FIN_WAIT_1↓ reçoit ACK
FIN_WAIT_2↓ reçoit FIN
TIME_WAIT↓ 2×MSL (~2 min)
CLOSED
🖥️ Côté serveur (ouverture passive)
CLOSED↓ passive open
LISTEN↓ reçoit SYN
SYN_RECEIVED↓ reçoit ACK
ESTABLISHED↓ reçoit FIN
CLOSE_WAIT↓ envoie FIN
LAST_ACK↓ reçoit ACK
CLOSED
Note : L'état CLOSE_WAIT côté serveur peut devenir un problème applicatif. Si une application serveur ne ferme pas ses sockets proprement (bug, fuite de ressource), les connexions restent bloquées en CLOSE_WAIT indéfiniment : diagnostic classique avec ss -antp | grep CLOSE_WAIT.
3
Pourquoi TIME_WAIT existe-t-il ?
L'état TIME_WAIT est souvent mal compris. Il est pourtant crucial pour la fiabilité de TCP, et peut devenir un goulot d'étranglement sur les serveurs à fort trafic.
t=0
1×MSL (60s) dernier ACK envoyé
2×MSL (60s) sécurité retransmission
CLOSED
🛡️ Pourquoi c'est nécessaire
Si le dernier ACK du client se perd, le serveur retransmet son FIN. Le client encore en TIME_WAIT peut alors répondre correctement.
Sans TIME_WAIT, une nouvelle connexion sur le même port pourrait recevoir un FIN parasite de l'ancienne session.
⚠️ Le problème en production
Sur un serveur HTTP à fort trafic, des milliers de connexions simultanées en TIME_WAIT peuvent épuiser les ports disponibles (plage 1–65535). Chaque port ne peut ouvrir qu'une connexion à la fois tant qu'il est en TIME_WAIT.
SO_REUSEADDRRéutilisation des ports en TIME_WAIT
tcp_tw_reuseLinux : réutilise si timestamps OK
TCP Fast OpenRFC 7413 : données dès le SYN
MSL (Maximum Segment Lifetime) est défini à 2 minutes dans la RFC 793 originale, mais la plupart des OS modernes utilisent 30 à 60 secondes. TIME_WAIT = 2×MSL garantit que tous les segments de l'ancienne connexion ont expiré sur le réseau avant qu'un port soit réutilisé.
4
Numéros de séquence : comment ça marche
Les numéros de séquence TCP ne comptent pas des paquets, mais des octets. Comprendre ce mécanisme est clé pour déboguer TCP et comprendre les attaques.
ISN Client
1000
→
Données envoyées
500 octets
→
ACK attendu
1500
Formule : ACK = Seq + Longueur_données
Le numéro d'ACK indique le prochain octet attendu.
Sécurité : ISN aléatoire (RFC 6528) : L'ISN (Initial Sequence Number) est choisi de façon cryptographiquement aléatoire au démarrage de chaque connexion. Les anciens OS utilisaient des ISN séquentiels, ce qui permettait à un attaquant de prédire l'ISN et d'injecter des segments forgés (TCP session hijacking). Un ISN aléatoire sur 32 bits rend cette attaque statistiquement impossible.
5
Sécurité : attaques liées au handshake
Le processus d'établissement de connexion TCP est lui-même une surface d'attaque. Deux menaces classiques exploitent directement le handshake.
⚡ Attaque 1 : SYN Flood (DDoS)
L'attaquant envoie des millions de SYN avec des adresses IP sources forgées (spoofing). Le serveur répond SYN-ACK et alloue une entrée dans sa SYN queue pour chaque demi-connexion, mais ne reçoit jamais l'ACK final.
✅ Connexions normales
Client légitimeServeur
SYN → SYN-ACK → ACK ✓ Connexion établie, mémoire libérée
✓
✓
✓
💀 SYN Flood en cours
Attaquant (IP forgées)Serveur
SYN → SYN-ACK → (jamais d'ACK) SYN queue pleine → refus connexions légitimes
✗
✗
✗
✗
✗
✗
✗
…
…
Défense : SYN Cookies (RFC 4987) : Le serveur encode l'état de la connexion dans le numéro de séquence SYN-ACK (cryptographic hash). Il n'alloue aucune mémoire avant de recevoir l'ACK final. Si l'ACK contient le bon numéro dérivé du cookie, la connexion est légitime. La SYN queue ne se remplit plus.
🕵️ Attaque 2 : TCP Session Hijacking
Principe
Un attaquant dans le même réseau observe un échange TCP et prédit le prochain numéro de séquence. Il injecte un faux segment avec ce numéro → le serveur le croit légitime.
Ancienne vulnérabilité
Les vieux OS (SunOS, certains BSD) utilisaient des ISN séquentiels ou prévisibles. L'attaquant pouvait calculer le prochain ISN à partir des connexions précédentes.
Protection moderne
RFC 6528 impose un ISN aléatoire et imprévisible. De plus, TLS chiffre le contenu et authentifie les parties : même si l'ISN était deviné, les données seraient inutilisables.
SYN Flood : Une attaque SYN Flood envoie des millions de SYN sans jamais répondre au SYN-ACK, saturant la table d'état du serveur. La parade : les SYN cookies (RFC 4987) permettent de ne rien stocker avant la confirmation du handshake complet.
6
Exercice : reconstituer le handshake
Les étapes d'une connexion TCP complète ont été mélangées. Cliquez sur chaque étape dans le bon ordre chronologique pour reconstituer la séquence.
Cliquez sur les étapes dans l'ordre correct : de l'établissement de la connexion jusqu'à sa fermeture.
Ordre attendu : SYN → SYN-ACK → ACK → DATA → FIN → ACK → FIN → ACK
Capture réelle d'un 3-Way Handshake TCP suivi d'un échange de données. Chaque flag TCP est visible dans la colonne Info. Cliquez sur une ligne pour décoder le paquet.