Qual è l'impatto della rimozione di TLS_RSA_WITH_RC4_128_SHA dalla suite di crittografia del mio server?

La suite di crittografia complessiva determina la compatibilità, non la presenza o l'assenza di un codice. Dovrai testare diverse configurazioni per scoprirlo.

Se stai già facendo test del server SSL Lab , allora questa è la tua migliore risorsa per determinare l'impatto del cambiamento. Quando dici di essere

setting up some new certificates and load balancers

che suggerisce che è possibile sperimentare modifiche a questi sistemi perché non sono ancora in produzione. Quindi rimuovere TLS_RSA_WITH_RC4_128_SHA ed eseguire nuovamente il Test server SSL e prestare attenzione alla sezione Simulazione handshake dei risultati. Questo ti dirà quali client avranno problemi, come la seguente configurazione in cui IE 6 su XP non è in grado di funzionare con la mia suite di crittografia:

Ora, quel server ha RC4 completamente disabilitato e gli unici due client che sono incompatibili sono IE 6 su XP e Java 6u45 - ma Java non riuscito perché" Il client non supporta i parametri DH > 1024 bit ", non" Protocollo o mismatch di suite di crittografia " che è quello che mi aspetterei di vedere se la mancanza di RC4 fosse il problema.

SSL Labs è uno strumento fantastico perché ti consente di giocare con diverse configurazioni per ottenere l'equilibrio tra sicurezza e compatibilità di cui hai bisogno. Sulla base dei miei risultati, ho il sospetto che tu possa farcela senza RC4 (il mio DH del mio server i requisiti sono relativamente nuovi per Apache , ad esempio). Ma questo è veramente un caso di YMMV . Potresti voler utilizzare cipherli.st per guidarti nel provare nuove configurazioni.

suite di crittografia hanno proprietà di sicurezza ben comprese come TLS RSA WITH RC4 128 SHA che utilizza RSA per lo scambio di chiavi, 128 bit RC4 per la crittografia di massa e SHA per hashing.

d'altra parte:

L'attacco BEAST è una vecchia debolezza accademica che è stata recentemente dimostrata applicabile nella pratica. Richiede che l'utente malintenzionato spii il link e lanci codice ostile sul client (e tale codice deve comunicare con il sistema di spionaggio esterno); gli autori di BEAST sono riusciti a eseguirlo quando il codice interno ostile utilizza Java o Javascript. La soluzione generica è passare a TLS 1.1 o 1.2, che sono immuni. Inoltre, questo riguarda solo i codici a blocchi in modalità CBC.

Se l'attacco BEAST potrebbe essere applicato ai tuoi utenti, non rimuoverlo ma è meglio usare un'altra suite di crittografia strong perché:

RC4 come codice stream è immune all'attacco BEAST. Pertanto, RC4 è stato ampiamente utilizzato come mezzo per mitigare l'attacco BEAST sul lato server. Tuttavia, nel 2013, i ricercatori hanno riscontrato più debolezze in RC4. Successivamente, l'abilitazione di RC4 sul lato server non era più consigliata.

AIUI se vuoi supportare IE 6 allora devi fondamentalmente supportare almeno uno dei TLS_RSA_WITH_RC4_128_SHA o TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Entrambi hanno i loro problemi. RC4 ha gravi problemi di bias del keytream. La CBC è stata colpita dagli attacchi di padding e IV (BEAST, POODLE ecc.)

Il consenso generale al momento sembra essere che se hai bisogno di supportare IE 6 allora TLS_RSA_WITH_3DES_EDE_CBC_SHA è un male minore di TLS_RSA_WITH_RC4_128_SHA