Quasi tutti gli attacchi attivi portano a una connessione interrotta. Ciò include l'interruzione della connessione TCP come suggerito o la manipolazione del payload, l'attivazione di un errore MAC, che a sua volta interrompe la connessione.
Le interruzioni TCP si sono verificate nella pratica. Mentre questo era contro bittorrent, e non con connessioni protette SSL, SSL su TCP non può prevenire questo tipo di attacco.
According to independent testing, Comcast injected reset packets into peer-to-peer connections, which effectively caused a certain limited number of outbound connections to immediately terminate. This method of network management was described in the IEEE Communications, May 2000 article "Nonintrusive TCP Connection Admission Control for Bandwidth Management of an Internet Access Link"
È importante notare che il software che utilizza TLS è in grado di distinguere connessioni interrotte da connessioni che sono state chiuse con garbo, perché una connessione chiusa con grazia termina con un messaggio "BYE" TLS, che non può essere falsificato da un utente malintenzionato.
DTLS su UDP potrebbe essere più robusto dal momento che non è possibile interrompere la connessione TCP. Ma ovviamente un utente malintenzionato può semplicemente ingoiare tutti i messaggi che impediscono il proseguimento della connessione.
SSL 2.0 non includeva un protocollo di terminazione verificato, quindi qualsiasi parte coinvolta in una connessione SSL 2.0 che ricevesse una chiusura a livello TCP non poteva determinare in modo affidabile se il peer volesse davvero chiudere la sessione SSL o meno. Questo è stato un grosso problema, specialmente con HTTP perché, in HTTP 1.0, è consentito non inviare un'intestazione Content-Length , affidandosi invece alla chiusura del supporto di trasporto sottostante per contrassegnare la fine dei dati. Quindi, il troncamento silenzioso era possibile.
Questo è stato risolto in SSL 3.0 e versioni successive (ad esempio TLS, perché TLS 1.0 è SSL 3.1). Vengono scambiati un paio di messaggi SSL "Alert" di tipo close_notify , e questi messaggi, come tutto il resto del tunnel, beneficiano della protezione della crittografia (in particolare l'integrità verificata).
Se ipotizziamo che TLS 1.2 sia solido e sicuro, allora c'è poco che un utente malintenzionato può fare se non interrompere il servizio. Può forzare una connessione chiusa (a livello TCP) ma entrambe le parti sapranno che qualcosa è successo. Più insidiosamente, un utente malintenzionato con il pieno controllo di uno dei router potrebbe rallentare la connessione, eliminando i pacchetti (forzando le implementazioni TCP ad emetterli nuovamente) e facendo altri brutti scherzi (ad esempio costringendo le parti a inviare pacchetti più piccoli inviando pacchetti ICMP falsi che affermano che non è possibile inoltrare un determinato pacchetto perché è troppo grande). L'attaccante può quindi inviare gli SSLers a caccia di oche per un lungo periodo, senza fare nulla di così grezzo e visibile come una terminazione di connessione. A causa della natura molto flessibile del TCP, l'utente malintenzionato potrebbe ridurre la larghezza di banda a, diciamo, 30 byte al secondo (emulando un modem 300 bauds ...), che è abbastanza simile alla totale interruzione nella pratica, tranne che i sistemi informatici alle due estremità crederei ancora che la connessione sia viva e vegeta, e non la lascerebbe cadere per iniziarne una nuova.
Non sono a conoscenza di alcun metodo per manipolare una sessione SSL / TLS stabilita. Un tale attacco può avere successo se un utente malintenzionato può in qualche modo ottenere accesso (o interrompere) la creazione della chiave di sessione simmetrica. Quindi, se la sessione SSL / TLS è longeva o memorizzata nella cache e l'avversario in qualche modo è riuscito ad accedere alla chiave di sessione, allora è possibile che l'avversario manipoli la sessione esistente.
Spostando alcuni livelli, è solitamente molto più facile installare alcuni * ware sul dispositivo vittima per intercettare / manipolare il traffico sugli endpoint. Se si riducono alcuni livelli, la terminazione della sessione è abbastanza banale, ma non necessariamente si qualifica come manipolazione della sessione. Tuttavia, spostati verso il basso di un livello e il lancio di un attacco l1 / l2 diventa fattibile. Fondamentalmente, MITM a l2 (arp cache avvelenamento) o l1 (fisicamente bridge) tocca nello stream.