Criptográficamente "roto" y simplemente "roto" son cosas diferentes, lo primero suele entenderse como "menos que fuerza bruta" (lo que aún puede ser increíblemente caro de lograr).
Aparte del hecho de que dos cifrados, AES y RC4, son diferentes internamente (cifrado de bloque CBC y cifrado de flujo respectivamente), las diferencias observables son que AES-256 es de 256 bits, y no tan rápido (como usted correctamente sugerir) como RC4 de 128 bits. La velocidad es a veces una razón citada para Google lo prefiere .
La parte "DHE" significa efímero Diffie-Hellman , que ofrece PFS , generalmente una buena cosa .
Tanto AES como RC4 son compatibles con SHA-1 y MD5 para la verificación de la integridad del mensaje; se prefiere el primero (se debe usar uno u otro, antes de TLSv1.2 que agregó más algoritmos).
Thomas Pornin resume muy bien los problemas de RC4 y BEAST aquí:
La vulnerabilidad de RC4 permite que la mayoría de los primeros 256 bytes de una conexión se adivinen con precisión al menos en las condiciones que:
- el contenido recuperable debe ser el mismo durante la duración del ataque
- el atacante debe capturar mucho de tráfico, unos 2 24 —2 32 de paquetes útiles (que puede distinguir como inicio de una sesión)
- el contenido adivinado sigue siendo útil (es decir, cookie de sesión HTTP) cuando termina
- la clave de sesión SSL no se recupera, solo el contenido parcial
Un rápido cálculo de la parte posterior del sobre indica que podría saturar un enlace wifi (por ejemplo, 20 Mbps) con el tráfico ideal que estaría viendo en aproximadamente 2 horas durante los primeros 3-4 bytes recuperados y alrededor de 10 días para una recuperación casi completa de los primeros 256 bytes. (Esto solo tiene en cuenta el ancho de banda, los requisitos de CPU del análisis son insignificantes.)
Este problema con RC4 es bastante antiguo , solo la cuantificación de los sesgos es nueva.
Recomendé los cifrados AES en RC4 (BEAST es un problema del lado del cliente, si el usuario todavía tiene un navegador vulnerable en este momento, es probable que haya problemas más grandes que resolver).
Aunque algunos de estos problemas son (IMHO) demasiado promocionados, el mejor resultado es un mayor progreso hacia la compatibilidad uniforme del cliente y el servidor para TLSv1.1 y posteriores. Alrededor del momento en que se publicó BEAST, el soporte fue bastante pobre .