Oggi Google ha annunciato la prima collisione SHA-1 e rilascia un PoC che è accessibile al pubblico 90 giorni dopo. Ecco la domanda: dovremmo usare TLSv1.2 solo perché la versione sotto 1.2 supporta SHA-1, non è protetto, ma non supporta SHA-2.
Oggi Google ha annunciato la prima collisione SHA-1 e rilascia un PoC che è accessibile al pubblico 90 giorni dopo. Ecco la domanda: dovremmo usare TLSv1.2 solo perché la versione sotto 1.2 supporta SHA-1, non è protetto, ma non supporta SHA-2.
TLS (e SSL) usato o usa SHA-1 in tre modi.
1.0 e 1.1 hanno utilizzato HMAC-SHA1 per integrità dei dati in quasi tutte le cipheresi (alcuni vecchi hanno usato HMAC-MD5 ma sono per lo più già caduti nel dimenticatoio). 1.2 aggiunge alcune nuove ciphersuites che usano HMAC-SHA2 (SHA-256 o SHA-384) e alcune nuove cipherrite che usano AEAD che combina l'integrità nella crittografia (in particolare AES o altri con GCM, AES con CCM e ChaCha20-Poly13505; in pratica solo AES-GCM e ChaCha sono comuni).
La costruzione HMAC blocca gli attacchi di collisione come quello nuovo per SHA1. I Ciphersuites che usano HMAC-SHA1 rimangono sicuri ora come prima, e sicuri come HMAC-SHA2 - che non è interamente, perché già c'erano e sono ancora attacchi non correlati all'hash . In particolare, tutti i cifrari HMAC usano RC4, che è gravemente indebolito e ora vietato dalle tutte vesioni di TLS, o cifrari in modalità CBC con MAC-then-encrypt, che sono stati soggetti a una serie di padding -oracle attack - e in 1.0 anche un attacco IV noto (BEAST). La correzione degli attacchi questi consiste nell'utilizzare le ciphersuites di AEAD (con né HMAC-SHA1 né HMAC-SHA2), che richiede 1.2. "SHAttered" non fa alcuna differenza. Dovresti già aver preferito 1.2 con AEAD non HMAC-SHA1 O HMAC-SHA2 , e dovresti ancora.
PRF e derivazione della chiave. 1.0 e 1.1 hanno utilizzato una combinazione di doppio HMAC-MD5 e doppio-HMAC-SHA1 per il PRF utilizzato nell'handshake per la derivazione della chiave e Finito; 1.2 usa doppio HMAC-SHA2. Come sopra HMAC protegge dall'attacco di collisione, più la derivazione della chiave e i dati finiti sono sostanzialmente incontrollabili da un utente malintenzionato. Nessuna differenza.
Certificati. TLS, incluso 1.2, di solito (anche se non del tutto) si basa sui certificati e sulle loro firme e l'attacco di collisione può mettere in pericolo le firme dei certificati in almeno alcuni casi . Questo era vero per MD5 con l'attacco "canaglia" di una decina di anni fa, e portato a un ritiro abbastanza rapido dei certificati MD5. La comunità ha riconosciuto per anni che i certificati SHA1 erano altrettanto a rischio: alle CA è stato vietato emettere certificati firmati SHA1 per almeno 2 anni, a seconda dell'autorità che si è passati, e alcuni (più?) Browser, altri client e server e molti strumenti (in particolare il tester ampiamente utilizzato da SSLLab) hanno messo in guardia più o meno rumorosamente e in modo intrusivo sui certificati firmati SHA1 da almeno un anno; ora, come le note del sito Web infranto, alcuni (molti?) inizieranno a rifiutare questi certificati.
Se stai ancora utilizzando i certificati firmati SHA1; stop. Questo vale per tutte versioni di TLS e anche per usi non SSL / TLS di certificati come la crittografia e la firma del codice.
Quindi, in conclusione, "SHAttered" non fornisce alcun motivo aggiuntivo per usare 1.2, ma c'era una già buona ragione per 1.2. Fornisce più motivi per utilizzare i certificati di SHA2, ovunque, non solo per TLS. L'unica vera ragione per passare a 1.2 a causa di "SHAttered" è perché la pubblicità, il rumore, il clamore, la paura e l'incomprensione diffusa ti danno la possibilità di fare leva su risorse e approvazioni da manager che non capiscono il problema.