Resumen

  • TLS 1.2 permitía iniciar otro handshake dentro de una conexión existente sin demostrar qué handshake anterior estaba continuando.
  • RFC 5746 guardó los valores verify_data del handshake previo y exigió que la renegociación los comprobara.

Dos handshakes correctos y una conversación falsa

El ataque comenzaba con una conexión TLS legítima, aunque iniciada por el atacante. Este enviaba al servidor datos de aplicación elegidos por él y después hacía pasar por esa conexión el handshake de una víctima. Para la víctima parecía un handshake inicial; para el servidor parecía una renegociación de la conexión del atacante.

El atacante no podía descifrar el tráfico protegido posterior. Pero el prefijo ya había llegado al servidor. Este podía observar los bytes elegidos por el atacante seguidos del tráfico autenticado de la víctima y tratarlos como una sola interacción. En HTTPS, una aplicación que no separara los estados podía relacionar esa entrada inicial con credenciales o cookies enviadas después.

No fallaba el cifrado ni se falsificaba un certificado. Cada handshake tenía sus propios mensajes Finished válidos. El fallo era de continuidad: el nuevo handshake no demostraba que fuera el sucesor del handshake y del flujo que la otra parte había visto.

Hacer que el último Finished forme parte del estado

RFC 5746 añadió una marca secure_renegotiation y almacenó, por conexión, los verify_data del cliente y del servidor correspondientes al handshake inmediatamente anterior. Esos valores pertenecían a la conexión activa, no simplemente a una entrada reutilizable de la caché de sesiones.

La extensión renegotiation_info, de tipo 0xff01, llevaba esa historia al siguiente intercambio. En el handshake inicial, renegotiated_connection estaba vacío. En una renegociación, el cliente enviaba su client_verify_data guardado. El servidor lo comparaba con su estado y devolvía la concatenación de los valores del cliente y del servidor. El cliente verificaba entonces su propia historia. Si faltaba una extensión obligatoria o había una discrepancia, el handshake terminaba con un error fatal.

La consecuencia interpretativa es importante: ya no bastaba con terminar correctamente un handshake. Tenía que ser el siguiente handshake correcto para esa conexión concreta.

Un código en la lista de suites que no era una suite

Algunas implementaciones antiguas fallaban al recibir extensiones desconocidas. Para atravesar ese límite, RFC 5746 definió TLS_EMPTY_RENEGOTIATION_INFO_SCSV, 0x00,0xFF, dentro de la lista de suites. Los equipos antiguos debían ignorar suites desconocidas, de modo que el cliente podía anunciar compatibilidad sin depender de un analizador de extensiones tolerante.

El SCSV no era una suite negociable y tampoco proporcionaba la vinculación de las renegociaciones posteriores. Era una señal del handshake inicial. Si el servidor no confirmaba la renegociación segura, el cliente debía elegir entre conservar la interoperabilidad o rechazar la posibilidad del ataque de empalme. TLS no permitía saber por sí solo si el servidor rechazaba toda renegociación o carecía de la reparación.

De reparar a eliminar

TLS 1.3 adoptó una frontera distinta: prohíbe la renegociación. Un ClientHello posterior en una conexión TLS 1.3 debe provocar un mensaje inesperado. Una conexión establecida con una versión anterior debe conservar esa versión si recibe un ClientHello de TLS 1.3 durante una renegociación: no puede actualizarse así a TLS 1.3. KeyUpdate y la autenticación posterior al handshake siguen existiendo, pero son mecanismos diferentes y no deben llamarse renegociación.

Para TLS 1.2, RFC 9325 exige que clientes y servidores implementen renegotiation_info, y que el cliente termine la conexión si el servidor no reconoce la extensión. RFC 5746 tampoco resolvió todos los problemas de múltiples handshakes; RFC 9325 trata por separado el secreto maestro extendido y el triple handshake. Su logro histórico fue más delimitado: hizo de la continuidad temporal una propiedad autenticada, no una suposición de la aplicación.

Fuentes