nonce nell'handshake SSL / TLS

Question

nonce nell'handshake SSL / TLS

#1 da (5 voti)
#2 da (1 voti)

5

Nell'handshake SSL / TLS, un nonce viene sempre inviato dal client al server e viceversa. Il nonce consiste fondamentalmente in un numero casuale e in un timestamp unix. Perché abbiamo bisogno del timestamp unix?

Poiché il nonce è sempre un numero casuale, in che modo questo protegge dall'attacco di replay da parte di un man-in-the-middle? Essendo una cosa casuale, lo stesso nonce potrebbe essere ripetuto in un'altra stretta di mano con lo stesso server.

Qualcuno può dirmi qualche altro scopo di questo nonce?

tls nonce

posta asit_dhal 04.06.2014 - 02:18

fonte

2 risposte

Leggi altre domande sui tag tls nonce

Come posso verificare che un'organizzazione sia quella che dicono di essere online? Sicurezza nei sistemi automatici che utilizzano Puppet and Chef

score 5 · Answer 1

Il server non dovrebbe mai consentire un duplicato nonce. Questo è ciò che protegge da un attacco di replay. Qualcuno può catturare e provare a inviare nuovamente il tuo messaggio, ma verrà negato perché quel nonce è stato registrato e non può essere riutilizzato.

Se si dispone di un timestamp e si negano le richieste precedenti a 5 minuti, è possibile cancellare la cache dei nonces utilizzati ogni 5 minuti. Puoi cancellare i tuoi nonces perché anche se ne hanno riprodotti uno a questo punto vedranno il timestamp scaduto e falliranno comunque. Ciò significa che non è necessario mantenere ogni nonce mai usato fino alla fine del tempo, il che si traduce in meno spazio di archiviazione e tempi di ricerca più rapidi.

score 1 · Answer 2

In TLS 1.2 e precedenti, il campo Random dei messaggi Client e Server Hello ha effettivamente una parte di byte casuali e un timestamp. Lo scopo del timestamp è aumentare la possibilità di avere un valore univoco anche se il generatore di numeri casuali è difettoso e produce byte casuali duplicati.

Questa non è la pratica corrente, le moderne implementazioni TLS inviano solo una sequenza completamente casuale a causa di problemi di privacy (perdite nell'ora locale). Per questo motivo la parte relativa all'ora è stata rimossa nella bozza TLS 1.3 .

I numeri casuali di entrambi i lati sono combinati con un altro segreto condiviso per formare una chiave di sessione (vedi RFC 5246 TLS, Calcolo chiave ). Pertanto, anche se una parte invia una sequenza casuale duplicata nel messaggio Hello Handshake, non darà come risultato la stessa chiave di sessione.