"Renegociación insegura" no se trata de la selección de conjuntos de cifrado; se trata de un tipo de ataque Man-in-the-Middle que va así:
- El atacante se conecta al servidor y realiza un primer protocolo de enlace.
- El atacante envía algunos datos (por ejemplo, una solicitud HTTP POST).
- El cliente se conecta al atacante y envía su secuencia de saludo inicial.
- El atacante reenvía los mensajes de reconocimiento del cliente al servidor y viceversa. Desde el punto de vista del cliente, este es el saludo inicial; Desde el punto de vista del servidor, esta es una renegociación dentro del contexto establecido inicialmente con el atacante.
- A partir de ese punto, el atacante reenvía ciegamente los datos. El servidor inicia algún mecanismo de autenticación con el cliente.
- El servidor considera erróneamente que el resultado de la autenticación cubre el diálogo completo , incluidos los datos que el atacante introdujo antes de la renegociación. Como resultado, el servidor puede aplicar la solicitud del atacante como si viniera del cliente autenticado.
RFC 5746 es un mecanismo (una extensión TLS) que tiene como objetivo diferenciar el protocolo de enlace inicial y el protocolo de renegociación. Si el cliente y el servidor lo admiten, entonces el servidor, en el escenario anterior, notará que el ClientHello en el segundo saludo se etiquetará como "inicial", no como "renegociación", y por lo tanto rechazará el intento. Cuando algún informe le dice que su servidor hace una "renegociación insegura", realmente le dice que su servidor no es compatible con RFC 5746. Esto no tiene ninguna relación con la selección del conjunto de cifrado, y no hay ningún cambio en su lista de conjuntos de cifrado. cualquier cosa a favor o en contra de eso; este es un ajuste ortogonal.
Uno puede notar que permitir una renegociación insegura no implica necesariamente un agujero explotable. Realmente depende de cómo el servidor maneja la autenticación del usuario, en particular con respecto a las renegociaciones. Conceptualmente, un servidor que recibe una solicitud no autenticada puede iniciar una renegociación (por ejemplo, con autenticación de cliente basada en certificados) y luego, después de el segundo protocolo de enlace, enviar un redireccionamiento HTTP para que el cliente envíe la solicitud nuevamente. En tal caso, no habría ningún problema con la falta de soporte de RFC 5746. Sin embargo, los servidores web existentes no funcionan de esa manera, por lo tanto, existe una necesidad común de "fortalecer" las renegociaciones sistemáticamente en el nivel TLS.
(En términos generales, el problema con las renegociaciones es que SSL / TLS proporciona seguridad solo en el sentido cronológico de avance, mientras que los usuarios de SSL / TLS, es decir, el servidor web, generalmente asumen que la seguridad también se extiende hacia atrás, incluso a través de renegociaciones. RFC 5746 corrige una modalidad de ataque conocida y explícita, pero no está claro, o al menos no está documentado, si realmente garantiza la autenticación hacia atrás hasta el saludo inicial.)