Las debilidades conocidas de RC4, en este momento (marzo de 2013), son sesgos estadísticos:
-
Los primeros bytes del flujo, especialmente el segundo byte, están bastante sesgados, lo que significa que si un atacante observa muchas sesiones SSL, podría hacer una buena suposición de cuál es el segundo byte enviado por el cliente o el servidor podría ser (al comienzo de la sesión). Pero eso no le enseñará mucho: el atacante ya sabe que el segundo byte enviado por el cliente es una 'E' (para una solicitud HTTP 'GET') y el segundo byte enviado por el servidor es una 'T' (para una respuesta HTTP, que siempre comienza con 'HTTP').
-
Otros sesgos son sobre pares de bytes que son menos probables de lo que deberían. El sesgo se puede exhibir después de observar un gigabyte de salida RC4. Pero observar un sesgo en las condiciones de laboratorio y deducir algo en datos encriptados son dos cosas diferentes. No se conoce ninguna forma de convertir este sesgo de RC4 en un ataque real a SSL (el escenario más plausible que he escuchado implica observar unos cuantos miles de millones de conexiones que contienen todos los mismos datos secretos, por ejemplo, una cookie o una contraseña, de manera confiable lugar predecible: solo llevaría unos pocos miles de años de espionaje del paciente).
Las debilidades conocidas de MD5, en este momento (marzo de 2013), son:
- No resistencia a las colisiones (desde el ataque de Wang en 2004).
- Debilidad teórica con respecto a las imágenes previas (pero con un costo de más de 2 123 , está bastante lejos en el ámbito de "solo teoría").
Ni afecta directamente a MD5 cuando se usa en SSL. De hecho, SSL usa MD5 como parte de HMAC , que tiene una "prueba de seguridad" que relaciona su seguridad con la compresión la función utilizada en MD5 es indistinguible de un PRF . Se sabe que la función de compresión de MD5 es no un PRF; se conoce desde 1996 y el trabajo de Dobbertin en esa función de compresión. Esto hace que la prueba de seguridad HMAC sea "inaplicable". Pero no se ha comprobado que el HMAC / MD5 sea seguro, no significa que se demuestre que es inseguro. Actualmente no se conoce ningún ataque real en HMAC / MD5. En consecuencia, su uso en SSL sigue siendo "seguro".
Esto se corrobora con la situación de MD4 , un antecesor de MD5. MD4 está muy roto en cuanto a colisiones, mucho más que MD5 (todavía se necesitan unos segundos para construir una colisión MD5, mientras que la misma máquina construirá millones de MD4 colisiones por segundo). También se conoce un ataque de preimagen en MD4, pero solo teórico (costo en 2 102 ). HMAC / MD4 tiene un ataque "casi práctico", lo que lleva a falsificaciones en 2 58 consultas (debe convencer al cliente o servidor SSL atacado para que calcule la cantidad de registros SSL que contiene). la misma sesión, en los datos que el atacante elige, antes de producir un registro falso). Esto significa que si SSL estaba usando MD4 en lugar de MD5, ahora sería "prácticamente seguro" y tendríamos "avisos de advertencia avanzados" sobre la necesidad de migrar a algo mejor. MD5 es, en todos los puntos, más robusto que MD4, por lo que no hay necesidad de entrar en pánico.
Y, por supuesto, nada de esto está relacionado con el certificado . Si el servidor desea usar RC4 o AES o MD5 o SHA-256 no está no escrito en el certificado, y está completamente fuera del alcance de lo que Verisign quiera hacer. El trabajo del certificado finaliza en el servidor clave pública , y no cubre lo que el servidor hace con esa clave pública, y mucho menos lo que hace el servidor con cualquier clave de sesión que se intercambió utilizando la clave pública.