Différences

Ci-dessous, les différences entre deux révisions de la page.

--- bloc3s1:tcp [2022/09/13 09:24] – [MTU discovery (PMTUD)] techer.charles_educ-valadon-limoges.fr
+++ bloc3s1:tcp [2022/10/03 22:20] (Version actuelle) – [Interruption de session] techer.charles_educ-valadon-limoges.fr
@@ Ligne 48: / Ligne 48: @@
 ==== Le numéro d'acquitement ====
 Quatrième champ : Numéro d ’acquittement 32 bits
-  * Numéro du prochain octet attendu par le récepteur, dans le flux TCP
+  * Numéro du prochain octet attendu par le récepteur (numéro de séquence), dans le flux TCP
-  * n’indique pas le numéro du dernier octet correctement reçu.
+  * L'annonce de ce numéro indique implicitement que tous les octets précédents (et donc les numéros de séquences précédents ont été bien reçus.
 {{ :bloc3s1:entetetcp_3.png |}}
 ==== Le champ Flags ====
-Septième champ : 6 drapeaux 6 foius 1 bit
+Septième champ : 6 drapeaux 6 fois 1 bit
-  * 3 premiers bits sont utilisés lors de l'**établisement de la connexion TCP** :
+  * 3 premiers bits sont utilisés lors de l'**établissement de la connexion TCP** :
     * **SYN** : **demande** d ’établissement de connexion
     * **ACK** : **validité** du numéro d ’acquittement en indiquant si le segment contient un acquittement ou pas
@@ Ligne 68: / Ligne 68: @@
 ===== La gestion de la communication TCP =====
-==== MTU ====
+ Lien : https://www.ionos.fr/digitalguide/serveur/know-how/presentation-de-tcp/
-Le MTU, ou **unité de transmission maximale (MTU)** représente le plus gros paquet de données qu’un appareil connecté au réseau acceptera.
-Au dela de cette taile, le paquet est divisé en plusieurs morceaux : **fragmentation du paquet**.
-Cela nécessite plus de temps car plus de paquets à transmettre et le destinataire devra rassembler les paquets.
-Une valeur optimale de MTU correspond à la valeur maximale que le réseau accepte. S’il est trop bas, cela ajoute de la latence.
 ==== MSS ====
@@ Ligne 85: / Ligne 77: @@
-Par défaut, sur un réseau Ethernet chaque trame peut faire jusqu’à 1 500 octets (MTU de 1520 octets), dont :
+Par défaut, sur un réseau Ethernet chaque trame peut faire jusqu’à 1 500 octets (MTU de 1500 octets), dont :
   * au moins 20 octets doivent être réservés à l’en-tête TCP
   * et 20 autres à l’en-tête IP.
@@ Ligne 108: / Ligne 100: @@
 </WRAP>
+<WRAP center round info>
+Pour définir un volume individuel de MSS, il suffit de le préciser dans le champ **Options** avant la transmission des premières données : l’expéditeur et le destinataire conviennent généralement du volume maximum des segments TCP à expédier : **Maximum Segment Size – MSS**. Cela est fait lors de l'établissment de la connexion TCP (3 way handshake).
+</WRAP>
+==== Attaque sur l'option MMS ====
+Annoncer des valeurs MMS très petites (**attaque par MMS faible**) pour limiter artificiellement les charges TCP échangées dans les deux sens de la connexion. Le principe est d'obtenir que la taille des paquets IP résultants soit inférieure à une valeur choisie.
+On force alors une taille de segments TCP très petite ce qui va multiplier de manière conséquente (jusqu'à supérieur à 14), le nombre de segments TCP à envoyer pour transporter la même quantité de données.
 ===== La gestion de la connexion TCP =====
@@ Ligne 126: / Ligne 130: @@
 Etablissement en **trois étapes** : le **3-Way Handshake**.
 {{ :bloc3s1:entetetcp_4.png |}}
-  - le client **envoie** un paquet (segment **SYN** ou synchronize) avec un numéro séquentiel aléatoire individuel.
-  - le serveur reçoit le segment et **approuve** la connexion en renvoyant un paquet **SYN-ACK** (acknowledgement = « confirmation »), ainsi que le numéro séquentiel du client augmenté de 1. Il transmet également au client son propre numéro séquentiel.
-  - le client **confirme** la réception du segment SYN-ACK en envoyant son propre paquet **ACK** qui contient le numéro **séquentiel du serveur augmenté de 1**. Simultanément, il peut transmettre ses premières données au serveur.
+  * Etape 1 : Le client demande l'établissement d'une session de communication avec le serveur en  **envoyant** un paquet (segment **SYN** ou synchronize) avec un numéro séquentiel aléatoire individuel.
+{{ :bloc3s1:9.2.2_01.png |}}
+  * Etape 2 : le serveur reçoit le segment et accuse réception de la session de communication en **approuvant** la connexion grâce à l'envoi d'une réponse **SYN-ACK** (acknowledgement = « confirmation »), ainsi que le numéro séquentiel du client augmenté de 1. Il transmet également au client son propre numéro séquentiel.
+{{ :bloc3s1:9.2.2_02.png |}}
+  * Etape 3 : le client **confirme** la réception du segment SYN-ACK en envoyant son propre paquet **ACK** qui contient le numéro **séquentiel du serveur augmenté de 1**. Simultanément, il peut transmettre ses premières données au serveur.
+{{ :bloc3s1:9.2.2_03.png |}}
+==== Interruption de session ====
+Pour mettre fin à une connexion, l'indicateur de contrôle FIN (Finish) doit être défini dans l'en-tête de segment.
+Pour mettre fin à chaque session TCP unidirectionnelle, on utilise un échange en deux étapes constitué d'un segment FIN et d'un segment ACK. Pour mettre fin à une seule conversation TCP, quatre échanges sont nécessaires pour mettre fin aux deux sessions. La terminaison peut être initiée par le client ou le serveur.
+Dans l'exemple, les termes client et serveur sont utilisés comme référence pour plus de simplicité, mais deux hôtes quelconques qui ont une session ouverte peuvent lancer le processus de terminaison.
+  * Étape 1. FIN : quand le client n'a plus de données à envoyer dans le flux, il envoie un segment dont l'indicateur FIN est défini.
+{{ :bloc3s1:9.2.3_01.png |}}
+  * Étape 2. ACK : Le serveur envoie un segment ACK pour informer de la bonne réception du segment FIN afin de fermer la session du client au serveur.
+{{ :bloc3s1:9.2.3_02.png |}}
+  * Étape 3. FIN : Le serveur envoie un segment FIN au client pour mettre fin à la session du serveur au client.
+{{ :bloc3s1:9.2.3_03.png |}}
+  * Étape 4. ACK : Le client répond à l'aide d'un segment ACK pour accuser réception du segment FIN envoyé par le serveur.
+{{ :bloc3s1:9.2.3_04.png |}}
+Quand la réception de tous les segments a été confirmée, la session est fermée.
+==== Le contrôle de la connexion TCP ====
+Les hôtes maintiennent l'état, suivent chaque segment de données au cours d'une session et échangent des informations sur les données reçues en utilisant les informations de l'en-tête TCP.
+TCP est un protocole full-duplex et chaque connexion représente deux sessions de communication à sens unique.
+Les six bits de contrôle du champ des bits de contrôle dans l'en-tête TCP indiquent la progression et l'état de la connexion. Ce sont également des indicateurs (bit qui est actif ou inactif).
+Les six indicateurs de bits de contrôle sont les suivants:
+  * **URG** - Champ de pointeur urgent significatif (Urgent pointer field significant)
+  * **ACK** - Indicateur d'accusé de réception utilisé dans l'établissement de la connexion et la fin de la session
+  * **PSH** - Fonction push (Push function)
+  * **RST** - Réinitialisation de la connexion en cas d'erreur ou de dépassement de délai
+  * **SYN** - Synchroniser les numéros de séquence utilisés dans l'établissement de connexion
+  * **FIN** - Plus de données de l'expéditeur et utilisées dans la fin de session
+==== Attaques possibles sur le séquencement ====
+  * Prédiction du système d’exploitation pour des OS qui utilisent toujours la même valeur initiale lors de l'établissement d'une session
+  * Vol de session TCP (session hijacking) : en connaissant de numéro de séquence initial, l'attaquant peut prédire les numéros de séquence des prochaines connexions, information utile pour forger des paquets destinés à voler  des données, clôturer une connexion ou placer des données illégitimes.