A quanto pare, in passato, un uomo nel mezzo era in grado di sconfiggere la sicurezza (riservatezza, per la precisione) di TLS semplicemente sopprimendo il messaggio ChangeCipherSpec
.
Si chiama "ChangeCipherSpec Drop" e sfortunatamente, sono riuscito a trovare solo poche informazioni su di esso online.
Alcune fonti hanno detto che l'autore dell'attacco avrebbe semplicemente rilasciato il messaggio ChangeCipherSpec
, altri erano meno precisi al riguardo e questo grafico ho trovato qui mostra sia il ChangeCipherSpec
che il Finished
messaggio barrato.
Le mie domande sono:
- Perché il server ha quindi inviato i dati del payload? Il server non dovrebbe attendere fino a quando non ha ricevuto i messaggi
ChangeCipherSpec
eFinished
dal client prima di inviare i propri messaggiChangeCipherSpec
eFinished
e solo di inviare dati di payload dopo? - Come viene attivato anche questo? Ci si aspetta che passi del tempo tra l'ultimo messaggio del server della prima metà della connessione stabilita (
ServerHelloDone
) e il primo messaggio del server della seconda metà della connessione stabilita. Un intero tempo di andata e ritorno, anche. In che modo il server non inizia semplicemente a inviare i dati di payload subito ogni volta. C'è un timeout davvero strano? - In che modo il
ChangeCipherSpec
del cliente non è arrivato e il server non ha inviato i dati del suo payload in chiaro? Non dovrebbe ilChangeCipherSpec
del server determinare il punto nel tempo dopo il quale il server invia solo dati crittografati?