Ehi studiando il protocollo SSL, mi chiedo come può qualcuno essere in grado di fare un attacco di replay se manca il server nonce? Tutto il materiale che trovo dice che i nonces lo impediscono, ma non ci sono esempi che specifichino perché o come
Se il server utilizza lo stesso nonce (chiamato " server_random " nella specifica SSL / TLS ) e il stesso ID di sessione rispetto a un precedente handshake, quindi un utente malintenzionato può inviare esattamente gli stessi pacchetti di quello che il client ha inviato durante quella sessione precedente e il server accetterà tutto. Almeno se il server utilizza una suite di crittografia a scambio di chiavi RSA (che è il caso più comune).
Questo può essere facilmente visto seguendo come vengono calcolati i vari elementi crittografici. Il messaggio ClientKeyExchange contiene il pre-master-secret, crittografato con la chiave pubblica del server; quel pacchetto può essere riprodotto ed è ancora una versione correttamente crittografata dello stesso pre-master-secret. Le chiavi di crittografia e MAC sono quindi derivate dal pre-master-secret, dal client_random e dal server_random , attraverso il "PRF" SSL / TLS che è deterministico. Quindi, se i rand sono invariati (cioè se il server usa lo stesso server_random di prima e l'utente malintenzionato invia lo stesso messaggio ClientHello rispetto alla sessione precedente) e anche il pre-master-secret rimane invariato, quindi il il server dedurrà le stesse chiavi simmetriche e accetterà quindi i pacchetti crittografati acquisiti come autentici.
L'utente malintenzionato che esegue il replay non otterrebbe ulteriori informazioni su come potrebbero apparire i dati dell'applicazione; l'attacco non è un attacco decrittante . Ma dal punto di vista del server, sembrerebbe una seconda autentica connessione volontaria. Per una connessione SSL utilizzata per una richiesta POST HTTPS per un pagamento con carta di credito, ciò significherebbe un doppio pagamento.
Fortunatamente, per ottenere un server SSL che utilizza sempre lo stesso server casuale e lo stesso ID di sessione, ci vuole incompetenza di grandezza non standard. Non sto dicendo che non accadrà mai; solo che succede raramente. In particolare, la specifica TLS insiste sull'idea che i primi quattro byte di client_random e server_random dovrebbero codificare la data e l'ora correnti, con una precisione di 1 secondo: se onorato, anche con un orologio malamente distorto, questo da solo assicura che un server con un RNG gravemente imperfetto utilizzi ancora un server_random distinto dopo un secondo.
Leggi altre domande sui tag cryptography tls attack-prevention nonce