Estaba leyendo sobre el uso de RC4 por Google y un respuesta en el sitio web de stackexchange declaró lo siguiente:
Sé que Google usa RC4 para la mayoría de sus servicios, y esta es la razón por la que uno no debería mantener abierto Gmail todo el tiempo ;-)
¿Es esto cierto? ¿Qué tipo de ataques se pueden hacer si estamos intercambiando información durante demasiado tiempo con RC4? ¿Y cuánto tiempo (o cuánto de los datos) es demasiado largo?
Hay sesgos conocidos en la salida RC4, especialmente en los primeros bytes de la secuencia. En el "escenario de Gmail", el cliente (navegador web) se conecta regularmente al servidor para sondear nuevos mensajes entrantes. Cada conexión implica el cifrado de los datos de solicitud con una nueva secuencia RC4; y todas las solicitudes contendrán el mismo valor secreto en el mismo lugar del flujo (la cookie HTTP). Con el tiempo, un atacante que observa los flujos puede hacer estadísticas para resolver los bytes de datos de dicho secreto. Consulte esta publicación del blog para más información. explicaciones.
Tenga en cuenta, sin embargo, que en la práctica no funciona (todavía) . El ataque es criptográficamente real; sin embargo, el "escenario de Gmail" no hace suficientes conexiones para permitir que los sesgos se vuelvan realmente peligrosos. El margen de seguridad es pequeño ( incómodamente pequeño), pero está ahí. Es decir, se necesitan millones de conexiones para que los sesgos comiencen a aparecer, y, además, los "bytes interesantes" para el atacante están un poco demasiado lejos en la secuencia (una solicitud HTTP comenzará por la cadena "verbo + ruta", luego otras cabeceras, la cookie llega solo después de unos cientos de bytes; los sesgos son más grandes al principio, pero cuanto más secreto está el secreto, menos eficiente es el ataque). Asumiendo una conexión cada minuto (Gmail no hace conexiones tan a menudo) aún tomaría 30 años de observaciones continuas para comenzar a obtener bytes secretos reales, incluso si la cookie aparece "temprano" en el encabezado HTTP.
Entonces, si bien estos sesgos suenan como una campana de advertencia, nos dicen que RC4 es inestable y que debemos tener cuidado de no usarlo, no significa que los SSL protegidos con RC4 se puedan romper de manera rutinaria. Google usa RC4 (es decir, admite RC4 y configuraron sus servidores para preferir RC4 siempre que sea posible) debido a todo el ruido que se hizo sobre el ataque de BEAST en los cifrados de bloque que utilizan CBC. La configuración del ataque BEAST es pesada y se demostró solo en condiciones de laboratorio; nunca visto en la naturaleza y los navegadores web incluyeron rápidamente contramedidas para que el ataque no funcione en la práctica. Entonces, en efecto, Google tiene que elegir entre dos ataques que no funcionan y hacer cosas que deshabiliten uno u otro (aunque en la práctica ninguno funciona). Esto no es un problema criptográfico; Este es un problema de relaciones públicas . En este momento, Google prefiere RC4 porque consideran que, a la vista del público en general , BEAST es "más aterrador" (tal vez porque BEAST se presentó como video de Youtube , mientras que los sesgos de RC4 se publicaron por primera vez como 335-diapositivas presentación técnica ; no es de extrañar que el primero sea más conocido por el público que el segundo).
En cualquier caso, Google puede cambiar la configuración de su servidor en cualquier momento. Mientras sigan los avances en criptología (lo hacen), todo estará bien.
Youtube estaba funcionando bien con RC4 / RSA en la lista negra en el navegador, y de repente hoy recibo este servidor enlace
No quiere ir más alto que TLS_RSA_WITH_RC4_128_SHA
A todos los efectos, parece que DOWNGRADED sus servidores de contenido: o
Lea otras preguntas en las etiquetas cryptography encryption tls cryptanalysis rc4