Per prima cosa: non farti prendere dal panico . Non fare nulla di avventato e prenditi il tempo per riflettere.
Le diapositive che sono apparse oggi descrivono nuovi risultati in bias in RC4 . RC4 genera un flusso dipendente dalla chiave di byte pseudo-casuali, che viene quindi sottoposto a XOR con i dati da crittografare (la decrittografia è identica). Era noto che l'uscita di RC4 era leggermente distorta, cioè alcuni valori di byte erano più probabili di altri, specialmente nei primi byte di output. Questo porta al possibile seguente attacco: assumendo che un dato messaggio segreto m viene ripetutamente crittografato, ogni volta con una chiave diversa ma sempre nella stessa posizione nello stream, quindi l'osservazione dei dati crittografati consentirebbe di recuperare il messaggio m . Infatti, se in posizione j il byte del flusso di chiavi x è più probabile di tutti gli altri 255 valori, e l'attaccante osserva che il valore di byte crittografato b accade più spesso, allora supporrà che x = b XOR p per il byte di testo in chiaro p , quindi p = x XOR b .
Di solito si supponeva che sebbene i pregiudizi di RC4 avessero di quel tipo, non erano veramente vulnerabili nell'uso pratico di RC4, ad esempio, SSL / TLS .
I nuovi risultati aggiungono un po 'più di pregiudizi a quelli che erano conosciuti, e in un modo più sistematico, e forniscono misure . Le misure confermano parzialmente la posizione sopra. Naturalmente, le diapositive tendono ad assumere una posizione apocalittica e ad avvertire di una rottura totale, perché: 1. i ricercatori devono fare un po 'di marketing e pubblicità sui loro risultati, in modo da attrarre finanziamenti, e 2. è la Bernsteine stile per gridare che la Fine dei Tempi è vicina e che tutti gli altri hanno torto.
Ciò che le figure dicono è che ci vogliono alcuni milioni di connessioni affinché l'attacco funzioni. In una pratica impostazione SSL / TLS, in cui il target è un valore del cookie, non si aprirà una nuova connessione più di una volta ogni 15 secondi circa, poiché il browser e il server "manterranno la connessione attiva", quindi prendere un anno di navigazione Web 24/7, sempre sullo stesso sito, sempre subito dopo il browser o il server ha deciso di chiudere la connessione corrente, per diventare suscettibile a questo attacco. Pertanto, non fatevi prendere dal panico. Non c'è motivo di affrettarsi e approfondire le impostazioni della suite di crittografia. Eppure.
RC4 dovrebbe essere gradualmente eliminato a tempo debito. In effetti, i pregiudizi sono lievi, ma più grandi di quanto previsto in precedenza ("noi" pensavamo che i "pochi milioni" fossero "1 miliardo circa" ). Il margine di sicurezza sta diventando piuttosto esiguo. RC4 ha avuto un revival ultimamente a causa dell'attacco BEAST, ma era già considerato come una misura temporanea. Infatti, l'attacco BEAST non funziona più perché sono state trovate soluzioni alternative.
Un modo per "aggiustare" RC4, che è stato suggerito molte volte, è quello di eliminare i primi 256 (o 512 o 1536 o qualsiasi altro) byte di output, poiché questi sono i più distorti di essi (la grafica nelle diapositive mostra abbastanza chiaramente). Ma questo non sarebbe compatibile con RC4-come-lo-conosciamo, quindi non avrebbe molto senso forzarlo su SSL / TLS. Se le librerie SSL devono essere modificate per implementare un algoritmo migliore, possono anche usare una che è già standardizzata, cioè GCM (vedi RFC 5288 per l'integrazione di GCM in SSL / TLS). Questo sarebbe meglio di un RC4 ricondizionato che avrebbe ancora altri pregiudizi (più sottili, ma ancora rilevabili, e non limitati ai primi byte di output).
Per ora , non fare nulla. Ma guarda cosa farà Google. Cosa fa Google, il mondo seguirà.
Su base immediata, se sei veramente che preoccupato, torna a AES / CBC (o anche 3DES / CBC), nonostante BEAST che, come spiegato sopra, non funziona più con un browser aggiornato (e se il browser non è aggiornato, l'utente ha problemi molto più urgenti da risolvere!).
In un mondo ideale, questo nuovo attacco, nonostante la sua mancanza di applicabilità immediata, spingerà i venditori a implementare TLS 1.2 + GCM e il Web sarà più sicuro.