Una connessione TCP può essere terminata da un utente malintenzionato se SSL / TLS è stato utilizzato per proteggere i dati nel segmento TCP?

Questo è interamente fattibile, con l'avvertenza che è necessario conoscere il numero di sequenza corretto richiesto dallo stack tcp di destinazione. (così da poterlo fare per tutte le connessioni a un server, devi essere sul server stesso o su un gateway per quel server).

Nota: più ci si allontana dalla pila target, più è probabile che si verificheranno problemi di temporizzazione con l'iniezione. (presumendo che si tratti di un'iniezione di pacchetti e non di un mitm completo)

So anche per esperienza che tali intercettazioni vengono rapidamente interrotte con un piccolo aggiornamento di sicurezza sullo stack di destinazione: (

Rst e fin saranno relativamente sorvegliati, potrebbe valere la pena guardare semplicemente a zero le dimensioni della finestra tcp? (solo un pensiero, è passato tanto tempo [da un decennio a questa parte!] da quando ho giocato con questa roba)

..but I would like to know HOW the communicating parties would know the connection is improperly terminated and why it is only interrupted.

L'intero punto di tcp per fornire connessioni affidabili, se si uccide la connessione, lo stack su ciascun lato lo sa. Viene interrotto solo perché quando la connessione si interrompe la maggior parte dei sistemi riproveranno la connessione, di solito senza nemmeno dirlo all'utente.

La mia risposta iniziale è al di sotto ("No ...") in un blocco, ma ho bisogno di correggerlo, perché penso che la mia risposta sia sbagliata. TCP in sé non garantisce l'immunità da replay e / o attacchi man-in-the-middle . In realtà, questo tipo di interruzione è comunemente noto come attacco di ripristino TCP . Il problema è che TCP non ha un'autenticazione integrata dei messaggi e TCP nuda non può garantire l'autenticità o la veridicità dei pacchetti - per ottenere ciò, è necessario fare affidamento su Transport Layer Security (TLS) in HTTPS. Se un'applicazione è in grado di rilevare un pacchetto fuori ordine o un FIN illegittimo, questo è un servizio ausiliario e non è specificato dallo standard TCP. Ora di seguito è la mia valutazione errata iniziale:

No, an attacker cannot successfully terminate a TCP connection with the injection of a 'FIN' packet, since TCP is a mutually contingent protocol that requires both parties agree (i.e., one side initiates a state change by sending declaration of intent, then it waits to receive acknowledgment of that intent, and then it will transact the state change) to the transaction for that transaction to be executed. This corresponds to the answer given in Brent Baccala's (editor) *Connected: An Internet Encyclopedia,* Third Edition where we find the following:

Case 2: TCP receives a FIN from the network If an unsolicited FIN arrives from the network, the receiving TCP can ACK it and tell the user that the connection is closing. The user will respond with a CLOSE, upon which the TCP can send a FIN to the other TCP after sending any remaining data. The TCP then waits until its own FIN is acknowledged whereupon it deletes the connection. If an ACK is not forthcoming, after the user timeout the connection is aborted and the user is told.

[Connesso: un'enciclopedia Internet con connessione TCP Chiudi] [5] Quindi, anche se il numero di sequenza del pacchetto è corretto, un "FIN" inaspettato non termina le comunicazioni tra i due computer in base alla descrizione del protocollo TCP. Non dimentichiamo: il ricevitore non solo emetterà una risposta al mittente riconoscendo il 'FIN', ma riceverà effettivamente due pacchetti in conflitto con lo stesso numero di sequenza - e a meno che il ricevitore non sia in grado di anticipare il 'FIN', verrà interrotto e la comunicazione continuerà o verrà riavviata all'ultimo stato concordato da entrambi i terminali.