So che il cifrario RC4 quando viene utilizzato con SSL è vulnerabile a determinati attacchi , che nel peggiore dei casi potrebbero comportare il furto di token di autenticazione. Ma RC4 è anche raccomandato come cifrario per mitigare l'attacco BEAST.
È una decisione strategica migliore, disabilitare RC4 e forse essere vulnerabile a BEAST o proteggere contro BEAST e proteggere contro l'attacco a cui è vulnerabile RC4?
In ogni caso, il client suggerisce ma il server sceglie . Sul lato client, è possibile specificare che si preferisce utilizzare AES se possibile, ma se il client supporta RC4 e il server vuole per usare RC4 se possibile, allora RC4 lo sarà. Ciò implica che non si può realmente "usare RC4 come ultima risorsa" (a meno che il codice client non sia un trucco, che non credo implementino i client mainstream SSL, ovvero non che annuncia il supporto RC4, a meno che non si abbia una connessione precedente i tentativi con altri pacchetti di crittografia non sono riusciti).
Un modo per vederlo è che SSL protetto con RC4 è decisamente migliore di nessun SSL. Un altro modo è che qualunque cosa tu faccia sul client, il server non può essere sottratto; si sta affidando al server i propri dati riservati. La scelta della suite di crittografia è responsabilità del server, e se il server non applica suite di crittografia appropriate (dal tuo punto di vista), allora forse non dovresti inviare i dati a un server così trascurato ...
I punti deboli noti di AES-CBC (l'attacco BEAST) non funzionano più se il tuo client (browser Web) è aggiornato (e dovrebbe davvero!). Le debolezze note di RC4 non sembrano funzionare in un contesto Web (perché lo sfruttamento della debolezza richiede milioni di connessioni, e ciò richiede tempo - inoltre, i primi pochi centinaia di byte di ogni richiesta contengono intestazioni HTTP che sono per lo più privi di interesse per l'attaccante). Quindi si può dire che: RC4 o non RC4, cioè non la domanda . Se disattivi o abiliti RC4, è molto improbabile che questa sia la più grande vulnerabilità di sicurezza o anche una vulnerabilità significativa .
Tuttavia, può aver senso disattivare RC4, o disabilitare AES-CBC, al fine di rispettare alcune regole inflessibili, o aumentare un "segno di sicurezza" (molto artificiale) che alcuni auditor sembrano molto affezionati, per ragioni che hanno più a che fare con la psicologia che con la crittografia.
La vulnerabilità di BEAST è stata elaborata lato client, quindi non è più un problema con i browser moderni.
RC4 è un cifrario più debole di altri poiché è stato dimostrato che ha un leggero pregiudizio, ma se usato con attenzione e in modo appropriato, non ci sono attacchi riusciti contro di esso.
Non puoi essere più sicuro che sicuro; se la tua crittografia non può essere interrotta, non importa quanto più non possa essere rotto. Quindi in questo senso, non ci sono motivi convincenti per evitare il codice.
Detto questo, non ha senso usare un codice distorto quando altri sono disponibili. Quindi, andando avanti, potresti anche preferire qualcos'altro. La ragione principale per cui RC4 è così persistente è che è l'ultimo vero codice di flusso in uso, rendendolo utile per le persone che vogliono evitare di pensare al concatenamento dei blocchi. I cifrari a blocchi sicuri sono abbastanza difficili da inventare; ma i codici di flusso sono su un livello completamente nuovo, quindi non è probabile che ne vedremo un altro.
Molto probabilmente RC4 continuerà ad avanzare; non esiste una sostituzione diretta convincente. Non lo preferirei, ma mi aspetto di continuare a vederlo.
Un sacco di persone che raccomandano RC4 per prevenire BEAST hanno ritrattato a causa degli attacchi su di esso; la soluzione corretta e lungimirante è l'aggiornamento del software alle specifiche TLS 1.1.
Strategicamente, le tue opzioni dipendono dalle tue abilità. Se sei autorizzato a dettare gli agenti utente che si connettono al tuo servizio, o sei disposto ad accettare che il tuo agente utente potrebbe non essere in grado di connettersi ad alcuni servizi se questo lo rende più sicuro, richiede il supporto per TLS 1.2.
C'è pochissimo che può essere fatto in modo significativo per proteggere gli utenti che usano software obsoleti con vulnerabilità note. Ciò include le persone che eseguono agenti utente ancora in grado di non meglio di SSLv3 e senza supporto per le modalità GCM.
Le suite di crittografia vengono negoziate in un ordine prioritario. Poiché alcune persone potrebbero ancora seguire il vecchio consiglio di preferire RC4 per mitigare BEAST, è probabile che sia una buona scelta disabilitare RC4, soprattutto se i tuoi user agent (o dei tuoi utenti) sono aggiornati.
Dato che gli attacchi pratici sono stati dimostrati con prerequisiti simili sia per BEAST che per RC4, la scelta è comunque uguale.