TLS_FALLBACK_SCSV no protege contra Logjam por el mismo motivo por el que realmente funciona. Ese mecanismo anti-fallback se basa en que el cliente lo coloque en el ClientHello y, en última instancia, forme parte de la entrada a la función hash que calcula el mensaje final Finished . Esto funciona solo siempre que el atacante activo no pueda romper el cifrado de protocolo de enlace de inmediato y corregir en tiempo real el contenido del mensaje Finished . Pero eso es exactamente lo que sucede con Logjam: el atacante modifica el mensaje ClientHello para incluir el conjunto de cifrado RSA de exportación como parte de las suites de clientes, de modo que el ClientHello que recibe el servidor no es lo que el cliente envía. Mientras está en eso, el atacante también puede modificar otras partes del ClientHello y el ServerHello que regresa como respuesta, por ejemplo. para modificar la versión máxima anunciada (desde TLS 1.2 hasta TLS 1.0) y eliminar TLS_FALLBACK_SCSV.
Las cosas van por ese camino:
- El cliente envía un
ClientHello que dice "TLS 1.2, puede usar DHE-RSA, TLS_FALLBACK_SCSV".
- El atacante cambia eso a
ClientHello que dice "TLS 1.0, puede usar solo DHE-EXPORT-RSA, no TLS_FALLBACK_SCSV".
- El servidor responde con un
ServerHello que dice "ok, TLS 1.0, DHE-EXPORT-RSA, sin reserva".
- El atacante vuelve a cambiar eso en un
ServerHello que dice "ok, TLS 1.2, DHE-RSA, su antirrevolucionario fue visto y bien procesado".
- El servidor envía los parámetros exportar DH, debidamente firmados, con un módulo de 512 bits. El atacante los dejó fluir como están al cliente.
- El cliente espera parámetros DH "normales", pero no se distinguen de los parámetros DH "exportados", excepto por el tamaño del módulo, y el cliente está totalmente satisfecho con hacer un DH débil si el servidor parece querer hacerlo (aparentemente , algunas versiones de Safari incluso aceptan utilizar un módulo de 16 bits ...).
- El protocolo de enlace continúa, utilizando este módulo de 512 bits que tanto el cliente como el servidor acuerdan usar (aunque uno de ellos lo considera "exportar" y no el otro).
- El atacante lo rompe de inmediato (gracias a su pequeño tamaño y módulo predecible), y así obtiene la clave de sesión que utilizan el cliente y el servidor.
- Al final del protocolo de enlace, tanto el cliente como el servidor calculan los mensajes
Finished que deben enviar y que deben recibir. Vieron distintos mensajes de protocolo de enlace (el atacante modificó el ClientHello y el ServerHello ) pero el atacante tiene, en ese punto, el cifrado y las claves MAC, para poder descifrar, parchear y volver a cifrar los mensajes Finished voluntad de mantener la ilusión.
Resumen: TLS_FALLBACK_SCSV es un mecanismo "anti-downgrade", pero cubre solo la versión del protocolo y, lo que es más importante, funciona solo mientras el handshake degradado Todavía es resistente a la rotura inmediata y total. Esto estuvo bien para POODLE, donde el ataque se produce solo después del saludo, cuando se envían los mensajes cifrados. Pero no para Logjam.
En cuanto a FREAK, es más o menos lo mismo, excepto que se basa en un error adicional en la implementación del cliente: el cliente debe aceptar el uso de una clave efímera enviada por el servidor aunque, desde el punto de vista del cliente , no se debe enviar dicha clave ya que el cliente no solicitó una suite de cifrado RSA de exportación (no hay una suite de cifrado RSA no exportable en SSL / TLS que aún use un par de claves RSA efímeras).
Si bien es tentador afirmar que el problema es un "defecto de protocolo" y radica en el hecho de que los parámetros de exportación DH no se pueden distinguir de los parámetros de DH que no se exportan (este es el punto de vista de los autores del ataque Logjam), Mi propio análisis es que el verdadero problema es que tanto el cliente como el servidor aceptan usar criptografía débil: el servidor con el apoyo voluntario de DHE-export, el cliente al aceptar hacer DH con un módulo demasiado corto.