Leggevo sull'uso di RC4 da parte di Google e un risposta sul sito web di stackexchange ha dichiarato quanto segue:
I know Google uses RC4 for most of its services, and this is the reason one shouldn't keep gmail opened all the time ;-)
È vero? Che tipo di attacchi si possono fare se scambiamo informazioni per troppo tempo usando RC4? e quanto tempo (o quanti dati) è troppo lungo?
Ci sono pregiudizi noti nell'output di RC4, specialmente nei primi byte del flusso. Nello "scenario Gmail", il client (browser Web) si collega regolarmente al server per eseguire il polling dei nuovi messaggi in arrivo. Ogni connessione implica la crittografia dei dati della richiesta con un nuovo flusso RC4; e tutte le richieste conterranno lo stesso valore segreto nello stesso posto nello stream (il cookie HTTP). Nel tempo, un utente malintenzionato che osserva i flussi può fare statistiche per calcolare i byte di dati del suddetto segreto. Vedi questo post del blog per alcuni spiegazioni.
Nota, tuttavia, che in pratica non funziona (ancora) . L'attacco è crittograficamente reale; tuttavia, lo "scenario Gmail" non esegue abbastanza connessioni per consentire che i bias diventino veramente pericolosi. Il margine di sicurezza è piccolo ( spiacevolmente piccolo), ma è lì. Vale a dire, ci vogliono milioni di connessioni affinché i bias inizino a comparire, e inoltre i "byte interessanti" per l'attaccante sono un po 'troppo in basso nello stream (una richiesta HTTP inizierà da la stringa "verbo + percorso", quindi altre intestazioni, il biscotto che arriva solo dopo poche centinaia di byte, i bias sono più grandi all'inizio, ma più il segreto è lontano, meno efficiente diventa l'attacco). Supponendo una connessione ogni minuto (Gmail non esegue connessioni così spesso) occorrerebbero ancora 30 anni di osservazioni continue per iniziare a ottenere i byte segreti effettivi, anche se il cookie appare "in anticipo" nell'intestazione HTTP.
Quindi, mentre questi pregiudizi suonano come un campanello d'allarme, dicendoci che RC4 è instabile e dovremmo essere cauti nell'usarlo, non significano che l'SSL protetto da RC4 possa essere interrotto di routine. Google utilizza RC4 (cioè, supporta RC4 e ha configurato i propri server per preferire RC4 quando possibile) a causa di tutto il rumore che è stato fatto circa l'attacco BEAST sui cifrari a blocchi che usano CBC. La configurazione di attacco di BEAST è pesante ed è stata dimostrata solo in condizioni di laboratorio; mai avvistato in natura; e i browser Web includevano prontamente contromisure in modo che l'attacco non funzionasse in pratica. Quindi, in effetti, Google deve scegliere tra due attacchi che non funzionano e fare cose che disabiliteranno l'uno o l'altro (sebbene in pratica nessuno dei due lavori). Questo non è un problema crittografico; questo è un problema di relazioni pubbliche . Al momento, Google preferisce RC4 perché ritiene che dal punto di vista del pubblico , BEAST sia "più spaventoso" (forse perché il BEAST è stato presentato come video Youtube considerando che i bias RC4 sono stati pubblicizzati inizialmente come presentazione tecnica di 335 diapositive , non c'è da meravigliarsi che il primo abbia avuto un pubblico migliore rispetto al secondo).
In ogni caso, Google può cambiare la configurazione del server in qualsiasi momento. Fintanto che tengono traccia dei progressi della crittologia (lo fanno), le cose andranno bene.
Youtube stava funzionando bene con RC4 / RSA nella blacklist nel browser, e ad un certo punto oggi ottengo questo server link
Non vuole andare più in alto di TLS_RSA_WITH_RC4_128_SHA
A tutti gli effetti sembra che abbiano DOWNGRADED i loro server di contenuti: o
Leggi altre domande sui tag cryptography encryption tls cryptanalysis rc4