¿Qué tan seguro es HTTPS con conjuntos de cifrado débiles?

8

Hoy me encontré con el sitio web enlace , que decía ser seguro debido al certificado de Verisign. Revisé el certificado por curiosidad (es lo primero que dicen, veamos qué tan seguro es el "seguro"), y fue RC4 de 128 bits con MD5 para la autenticación de mensajes.

Según mi conocimiento, AES es el mejor algoritmo de cifrado simétrico actual. RC4 también parece estar bien, pero Wikipedia argumenta en contra de su uso en nuevos sistemas. Y luego MD5 ... A pesar de las muchas críticas, parece ser lo suficientemente seguro cuando no tienes una recompensa lo suficientemente grande como para un hash, pero todavía hay muchas críticas sobre su uso.

También tenga en cuenta que el texto claro se conoce parcialmente aquí, como partes del <head> y ciertamente el doctype. No estoy seguro de si esto se puede usar en un ataque con RC4 sin embargo.

Entonces, ¿qué tan seguro es este ciphersuite realmente? ¿Qué se necesitaría para manipular esta conexión? ¿O qué se necesita para leer los datos transmitidos, dado un tiempo ilimitado? ¿Y hay suites aún más bajas en uso, por ejemplo en los navegadores comunes pero algo anticuados (como FF3.6, IE8, etc.)?

    
pregunta Luc 19.08.2012 - 03:19
fuente

3 respuestas

8

RC4 ahora no se considera seguro, hay documentos que prohíben explícitamente su uso en TLS: RFC7465 .

Debes no utilizar RC4 actualmente.

la publicación actualizada como información obsoleta sobre crypto es peligrosa

Información obsoleta, publicada en 2012:

RC4 es seguro, de hecho, si no estás usando TLS 1.2, deberías usar RC4 para protegerte de BEAST.

MD5 es inseguro, pero si se usa como una función MAC aún no está roto

Para su crédito, si ha deshabilitado el hash MD5, negociará con SHA-1, de hecho, si deshabilita RC4, negociará AES: enlace

    
respondido por el Hubert Kario 19.08.2012 - 03:48
fuente
7

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.

    
respondido por el Thomas Pornin 03.03.2013 - 18:44
fuente
3

No hay ataques conocidos en este conjunto de cifrado. No lo llamaría "débil". Elegir este conjunto de claves no es lo que yo llamaría la mejor práctica, pero si alguien más ha hecho la elección por usted y no puede utilizarlo, probablemente estará bien. Es poco probable que sea el enlace más débil de su sistema.

    
respondido por el D.W. 19.08.2012 - 08:45
fuente

Lea otras preguntas en las etiquetas