In pratica, molti server HTTPS ampiamente distribuiti chiudono bruscamente le connessioni, senza alcun preavviso, e in particolare senza close_notify . Lo fanno perché vogliono uccidere le connessioni che sono rimaste inattive per troppo tempo (ad esempio, più di 30 secondi), e vogliono farlo anche se la connessione era inattiva perché il client è sparito (ad es. intervallo del punto di accesso WiFi, o qualsiasi altra situazione simile) e in realtà non riconoscerà il close_notify .
Sarebbe tecnologicamente fattibile per un server inviare un close_notify anche a un client morto e pulire ancora correttamente le risorse, ma molti progettisti di server trovano più semplice semplicemente non inviare close_notify (questo consente di mantenere Motore SSL e gestione socket separati). Ciò è in contraddizione con lo standard TLS , ma sappiamo che gli sviluppatori del mondo reale hanno un misterioso capacità di "tagliare gli angoli" quando lo ritengono opportuno. Notare che TLS 1.1 e 1.2 riconoscono la pratica diffusa di non inviare un close_notify , considerando che tale errore non invalida la sessione di TLS nel suo insieme (la sessione può quindi essere ripresa su altre connessioni ):
close_notify
This message notifies the recipient that the sender will not send
any more messages on this connection. Note that as of TLS 1.1,
failure to properly close a connection no longer requires that a
session not be resumed. This is a change from TLS 1.0 to conform
with widespread implementation practice.
Conseguenze non sono necessariamente cattive. Il close_notify è necessario per la sicurezza quando il protocollo dell'applicazione non è auto-terminato. Ad esempio, con HTTP-0.9, il client sa che la fine del documento richiesto viene raggiunta perché la connessione è chiusa; la mancanza di un close_notify significa che un attacco di troncamento è possibile (l'attaccante forza intenzionalmente una connessione TCP vicino "presto"). Tuttavia, con HTTP-1.0 e versioni successive, i corpi delle richieste e delle risposte hanno un Content-Length esplicito o utilizzano la codifica di trasferimento "chunked", che identifica in modo inequivocabile la fine del corpo. Per un protocollo auto-terminato come HTTP-1.0, il close_notify non è necessario per la sicurezza.
Una situazione in cui close_notify è assolutamente necessaria è per i protocolli che scambiano dati prima e dopo la sessione SSL / TLS, sulla stessa connessione (il STARTTLS metodo). In tal caso, il client e il server non possono inviare dati reciprocamente in modo affidabile sulla connessione dopo la chiusura SSL se non hanno contrassegnato la chiusura con close_notify messaggi.
Per riassumere , puoi formalmente reagire a una mancanza di close_notify come un attacco in corso o un errore di rete, ma se il tuo protocollo di comunicazione è auto-terminato , quindi puoi semplicemente ignorare la mancanza di close_notify .