So che questa domanda sembra molto sciocca, ma mi ha infastidito per un po 'e non riesco a trovare una risposta da solo. Quindi, qui va ..
I pacchetti nel protocollo TLS sono costituiti da un'intestazione di 5 byte seguita da dati crittografati una volta che l'handshake è terminato. L'intestazione a 5 byte viene sempre trasmessa in chiaro e contiene anche un campo di lunghezza di 2 byte.
Ora, l'attaccante MiTM può solo modificare il campo della lunghezza da solo nell'intestazione, così che la parte ricevente finisce per aspettare una grande quantità di dati, anche dopo aver ricevuto la quantità effettiva di byte originariamente inviati dal lato del pari. Ad esempio: diciamo che il peer side ha inviato un pacchetto di 20 byte e l'attaccante MiTM modifica solo il campo della lunghezza dell'header per renderlo 65535 byte. Ora, se nessun altro dato viene inviato dal peer, il lato ricevente aspetterà indefinitamente per ricevere i 65515 byte (65535-20) che non sono mai stati inviati in primo luogo.
Il TLS include l'intestazione nel calcolo MAC, quindi qualsiasi manomissione dell'intestazione causerà un errore e una chiusura effettiva della connessione. Ma come si risolve il problema del blocco su socket per ricevere i dati?
Il ricevitore può evitarlo usando un socket non bloccante con select (di nuovo select dovrebbe avere un timeout) o usando timeout con socket. Ma, che ne dici del caso di bloccare le prese? Esiste comunque un modo per evitare il blocco del lato ricevente sulla presa?