Three way handshake: una connessione inizia e finisce così.
Comunichiamo – Three way handshake
Nel vasto panorama della comunicazione informatica, uno degli aspetti fondamentali che sottolinea l’affidabilità e la sicurezza delle trasmissioni è il cosiddetto “Three-way Handshake.” Questa procedura, spesso considerata uno dei pilastri della comunicazione TCP/IP, è un elemento cruciale che sta alla base della stabilità delle connessioni di rete.
Cercherò di spegare come questo processo consente l’inizio di una connessione affidabile tra mittente e destinatario, garantendo al contempo l’integrità e la correttezza dei dati trasmessi. Inoltre mostrerò i vari passaggi coinvolti nel Three-way Handshake, mettendo in evidenza l’importanza di ciascuno di essi nel garantire che la connessione sia stabilita in modo affidabile e sicuro.
Three way handshake
Ci sono due scenari in cui avrà luogo una connessione Three way :
Stabilire una connessione (un’apertura attiva)
Terminare una connessione (una chiusura attiva)
Un handshake a tre vie (Three-way handshake) è un metodo utilizzato in una rete TCP/IP per creare una connessione tra un host/client locale e un “server”. Si tratta di un metodo in tre fasi che richiede sia al client che al server di scambiare i pacchetti SYN e ACK (riconoscimento-acknowledgment) prima dell’inizio della comunicazione dei dati.
Il livello Transmission Control Protocol (TCP) del protocollo di trasporto TCP/IP è orientato alla connessione. Orientato alla connessione significa che, prima che qualsiasi dato possa essere trasmesso, deve essere ottenuta e riconosciuta e stabilita una connessione affidabile. Le trasmissioni di dati a livello TCP, la creazione della connessione e la terminazione della connessione mantengono parametri di controllo specifici che governano l’intero processo.
I bit di controllo sono elencati come segue:
URG: campo puntatore urgente “significativo”
ACK: campo di conferma “significativo”
PSH: Funzione Push
RST: Reset della connessione
SYN: sincronizza i numeri di sequenza
FIN: Non ci sono più dati dal mittente
Funziona così:
- Un client invia un pacchetto dati SYN su una rete IP a un server sulla stessa rete o a una rete esterna. L’obiettivo di questo pacchetto è di chiedere se il server è disponibile per nuove connessioni.
- Il server di destinazione deve disporre di porte aperte in grado di accettare e avviare nuove connessioni. Quando il server riceve il pacchetto SYN dal nodo client, risponde e restituisce una ricevuta di conferma, il pacchetto ACK o SYN/ACK.
- Ilclient riceve il SYN/ACK dal server e risponde con un pacchetto ACK.
- Al termine di questo processo, viene creata la connessione e l’host e il server sono in grado di comunicare.
Vediamo
- A invia un segmento SYN a B – il flag SYN è impostato a 1 e il campo Sequence number contiene il valore x che specifica l’Initial Sequence Number di A;
- B invia un segmento SYN/ACK ad A – i flag SYN e ACK sono impostati a 1, il campo Sequence number contiene il valore y che specifica l’Initial Sequence Number di B e il campo Acknowledgment numbercontiene il valore x+1 confermando la ricezione del ISN di A;
- A invia un segmento ACK a B – il flag ACK è impostato a 1 e il campo Acknowledgment number contiene il valore y+1 confermando la ricezione del ISN di B.
Il terzo segmento non sarebbe, idealmente, necessario per l’apertura della connessione in quanto già dopo la ricezione da parte di A del secondo segmento. Entrambi gli host hanno espresso la loro disponibilità all’apertura della connessione. Tuttavia esso risulta necessario al fine di permettere anche all’host B una stima del timeout iniziale, come tempo intercorso tra l’invio di un segmento e la ricezione del corrispondente ACK.
Ricapitoliamo.
Più che ricapitolare, scendiamo più in profondità.
L’apertura di una “connessione attiva” viene eseguita inviando un pacchetto SYN al server. In questo pacchetto il flag “Synchronize sequence number” viene impostato a 1.
Il Synchronize sequence number posto ad 1 fa scaturire la richiesta al server di sincronizzare i numeri di sequenza; specifica il suo numero di sequenza iniziale (ISN), che viene incrementato di 1, per esempio 5683458+1=5683459, e che viene inviato al server.
In risposta, il server risponde con un pacchetto SYN-ACK in cui sia il campo Acknowledgement che il campo Synchronize sequence number sono impostati a 1.
Il server sta riconoscendo la richiesta di sincronizzazione del client.
Allo stesso tempo, il server sta anche inviando la sua richiesta al client per la sincronizzazione dei suoi numeri di sequenza.
C’è una differenza importante in questo segmento. Il server trasmette un numero di conferma (5683460) al client. L’acknowledgement è solo una prova per il client che l’ACK è specifico per il SYN che il client ha inizializzato. Il processo di riconoscimento della richiesta del client permette al server di incrementare il numero di sequenza del client di uno e lo usa come numero di riconoscimento.
Infine il client invia un pacchetto con il bit ACK (Acknowledgement field) impostato di nuovo al server.
In questo pacchetto, il client sta riconoscendo la richiesta di sincronizzazione del server. Il client utilizza lo stesso algoritmo implementato dal server per fornire un numero di riconoscimento. La conferma da parte del client della richiesta di sincronizzazione del server completa il processo di instaurazione di una connessione affidabile, quindi l’handshake a tre vie.
Si noti che per ogni connessione c’è un numero di sequenza di invio e un numero di sequenza di ricezione. Il numero di sequenza iniziale di invio (ISN o ISS) è scelto dal TCP che invia i dati, e il numero di sequenza iniziale di ricezione (IRS) è stabilito durante l’handshake TCP.
Selezione del numero di sequenza iniziale.
Si ma come si sceglie il numero iniziale? e se ci sono duplicati come si fa a capire di quale gruppo di sequenza appartiene il “pacchetto”?
Il protocollo non pone alcuna restrizione sul fatto che una particolare connessione sia usata più e più volte. Una connessione è definita da una coppia di socket. Le nuove istanze di una connessione saranno indicate come “incarnazioni” della connessione. Il problema che sorge da questo è — “come fa il TCP ad identificare i segmenti duplicati dalle precedenti “incarnazioni” della connessione? Questo problema diventa evidente se la connessione viene aperta e chiusa in rapida successione, o se la connessione si interrompe con perdita di memoria e viene poi ristabilita.
Per evitare confusione dobbiamo evitare che i segmenti di una “incarnazione” di una connessione siano usati mentre gli stessi numeri di sequenza possono essere ancora presenti nella rete da una precedente “incarnazione”.
Anche se un TCP va in crash e perde tutta la conoscenza dei numeri di sequenza che ha usato, quando vengono create nuove connessioni, viene impiegato un generatore di numero di sequenza iniziale (ISN) che seleziona un nuovo ISN a 32 bit.
Il generatore è legato a un orologio ( presumibilmente fittizio) di 32 bit il cui bit di ordine inferiore è incrementato approssimativamente ogni 4 microsecondi.
Ricordate 4,55 !
Così, l’ISN cicla approssimativamente ogni 4,55 ore.
Dal momento che assumiamo che i segmenti rimarranno nella rete non più della durata massima del segmento (MSL) e che l’MSL è inferiore a 4,55 ore, possiamo ragionevolmente assumere che gli ISN saranno unici.
Per ogni connessione c’è un numero di sequenza di invio e un numero di sequenza di ricezione.
Il numero di sequenza iniziale di invio (ISS) è scelto dal TCP che invia i dati, e il numero di sequenza iniziale di ricezione (IRS) viene conosciuto durante la procedura di creazione della connessione.
Per stabilire o inizializzare una connessione, i due TCP devono sincronizzarsi sui numeri di sequenza iniziale dell’altro. Questo viene fatto in uno scambio di segmenti per stabilire la connessione che portano un bit di controllo chiamato “SYN” (per sincronizzare) e i numeri di sequenza iniziali. Come abbreviazione, i segmenti che portano il bit SYN sono anche chiamati “SYN”. Quindi, la soluzione richiede un meccanismo adatto per scegliere un numero di sequenza iniziale e un handshake leggermente coinvolto per scambiare gli ISN.
Ricordate sulla connessione Three way …
Il flag SYN risulta utile nell’implementazione pratica del protocollo, e nella sua analisi da parte dei firewall: nel traffico TCP i segmenti SYN stabiliscono nuove connessioni, mentre quelli con il flag non attivo appartengono a connessioni già instaurate.
I segmenti utilizzati durante l’handshake sono solitamente ‘solo header’. Hanno il campo Data vuoto essendo questa una fase di sincronizzazione tra i due host e non di scambio di dati.
Il three-way handshake si rende necessario poiché la sequenza numerica (ISN) non è legata ad un clock generale della rete. Ogni pacchetto IP può avere il proprio modo di calcolare l’Initial Sequence Number. Alla ricezione del primo SYN non è possibile sapere se la sequenza ricevuta appartenga ad un ritardo dovuto ad una precedente connessione.
Tuttavia, viene memorizzata l’ultima sequenza usata nella connessione, potendo così essere richiesta la verifica all’ host mittente del SYN appartenente alla vecchia connessione.
Perchè ricordare ? Perchè vedremo come vengono sfruttate queste caratteristiche per eseguire un SYN flood. Un SYN flood è una forma di attacco denial-of-service in cui un attaccante invia una serie di richieste SYN ad un sistema nel tentativo di consumare risorse server sufficienti per rendere il sistema non più reattivo al traffico legittimo.
Key : connessione Three way , Three way handshake , connessione Three way