Lo primero es lo primero: no te asustes . No hagas nada precipitado y tómate tiempo para pensar.
Las diapositivas que han aparecido hoy describen nuevos resultados en sesgo en RC4 . RC4 genera una secuencia de bytes pseudoaleatorios dependiente de la clave, que luego se XOR con los datos para cifrar (el descifrado es idéntico). Se sabía que la salida de RC4 estaba ligeramente sesgada, es decir, algunos valores de byte eran más probables que otros, especialmente en los primeros bytes de salida. Esto conduce al posible siguiente ataque: asumiendo que un mensaje secreto dado m se cifra repetidamente, cada vez con una clave diferente pero siempre en la misma posición en la transmisión, luego, observar los datos cifrados permitiría recuperar el mensaje m . De hecho, si en la posición j el byte de flujo de clave x es más probable que todos los otros 255 valores, y el atacante observa que el valor del byte cifrado b sucede más a menudo, luego adivinará que x = b XOR p para el byte de texto simple p , por lo tanto p = x XOR b .
Generalmente se asumió que aunque RC4 tiene sesgos de ese tipo, no eran realmente vulnerables en el uso práctico de RC4 en, por ejemplo, SSL / TLS .
Los nuevos resultados agregan algunos sesgos más a los que se conocían, y de una manera más sistemática, y dan medidas . Las medidas confirman parcialmente la postura anterior. Por supuesto, las diapositivas son propensas a adoptar una postura apocalíptica y a advertir sobre una rotura total, porque: 1. los investigadores deben hacer un poco de mercadeo y publicidad sobre sus resultados, para atraer financiamiento, y 2. es el Bernsteinesque estilo para gritar que el fin de los tiempos está cerca, y que todos los demás están equivocados.
Lo que dicen las figuras es que se necesitan algunos millones de conexiones para que el ataque funcione. En una configuración práctica de SSL / TLS, donde el objetivo es un valor de cookie, no abrirá una nueva conexión más de una vez cada 15 segundos aproximadamente, porque el navegador y el servidor "mantendrán la conexión activa", por lo que tome un año de navegación por la Web 24/7, siempre en el mismo sitio, siempre inmediatamente después el navegador o el servidor decidieron cerrar la conexión actual para ser susceptibles a este ataque. Por lo tanto, no se asuste. No hay razón para apresurarse y profundizar en la configuración de la suite de cifrado. Sin embargo.
RC4 aún debería eliminarse a su debido tiempo. De hecho, los sesgos son leves, pero más grandes de lo que se esperaba anteriormente ("nosotros" pensamos que los "pocos millones" eran "1 billón más o menos" ). El margen de seguridad se está volviendo bastante delgado. RC4 tuvo un resurgimiento últimamente debido al ataque BEAST, pero ya fue considerado como una medida temporal. De hecho, el ataque BEAST ya no funciona porque se encontraron soluciones.
Una forma de "arreglar" RC4, que se ha sugerido muchas veces, es eliminar los primeros 256 (o 512 o 1536 o lo que sea) bytes de salida, ya que estos son los más sesgados de ellos (los gráficos en las diapositivas mostrar eso con bastante claridad). Pero esto no sería compatible con RC4-tal como lo conocemos, por lo que no tendría mucho sentido forzar eso en SSL / TLS. Si las bibliotecas SSL deben modificarse para implementar un mejor algoritmo, también pueden usar una que ya está estandarizada, es decir, GCM (consulte RFC 5288 para la integración de GCM en SSL / TLS). Esto sería mejor que un RC4 restaurado que aún tendría otros sesgos (más ligero, pero aún detectable, y no limitado a los primeros bytes de salida).
Por ahora , no hagas nada. Pero mira lo que hará Google. Lo que haga Google, el mundo seguirá.
De forma inmediata, si realmente está preocupado , vuelva a cambiar a AES / CBC (o incluso a 3DES / CBC), a pesar de BEAST, que, como se explicó anteriormente, ya no funciona con un navegador actualizado (y si el navegador no está actualizado, entonces el usuario tiene muchos más problemas urgentes que resolver).
En un mundo ideal, este nuevo ataque, a pesar de su falta de aplicabilidad inmediata, incitará a los proveedores a implementar TLS 1.2 + GCM, y la Web será más segura.