Perdita dell'ora locale in TLS tramite nonce composta da timestamp

0

Stavo leggendo sul cifrario dei blocchi di cifratura basato su nonce (CBC) e l'autore ha notato come nella storia di TLS, il nonce non è stato crittografato prima di diventare un vettore di inizializzazione (IV), portando a un IV prevedibile e quindi leader di attacco significativo su TLS.

Si è anche notato che siccome SSL poteva contare su TCP per consegnare i pacchetti in ordine, il nonce poteva anche essere lasciato fuori dal payload, lasciato implicito dallo stato della connessione, non lasciando un attacco di testo in chiaro ( CPA) sicuro.

Leggere ulteriormente come TLS usa un nonce mi ha portato alla domanda a nonce in SSL/TLS handshake . Dove ho trovato un commento interessante di @Lekensteyn:

In TLS 1.2 and before, the Random field of the Client and Server Hello messages indeed have a random bytes part and a timestamp. The purpose of the timestamp is to increase the chance to have a unique value even if the random number generator is flawed and produces duplicate random bytes.

This however is not the current practice, modern TLS implementations just send a completely random sequence due to privacy concerns (leaking the local time). For this reason the time part has been removed in the TLS 1.3 draft.

Mi piacerebbe saperne un po 'di più su questa storia di questo problema sopra, e forse perdendo l'ora locale. Ho rintracciato il repository github ( link ) per la bozza TLS 1.3, ma non ho trovato alcuna discussione su questo argomento. Se ne sai di più o puoi citare dove specificamente in un risultato, potrei leggere di più, mi piacerebbe sentirlo qui.

    
posta ruffsl 08.12.2016 - 02:17
fonte

0 risposte

Leggi altre domande sui tag