Resumen

  • La renegociación original ejecutaba un nuevo saludo dentro del canal cifrado, pero no vinculaba criptográficamente ambos saludos.
  • RFC 5746 añadió la memoria verificable del saludo previo; TLS 1.3 eliminó la renegociación y separó otras transiciones posteriores.

Cuando una conexión reunió a dos autores

El atacante abre primero una conexión TLS legítima con el servidor y envía un prefijo elegido de la capa de aplicación. Puede ser el principio de una solicitud que cobrará otro sentido al recibir más bytes. Después deja pasar por esa conexión el nuevo saludo TLS de una víctima.

La víctima cree estar iniciando su primera conexión con el servidor auténtico. El servidor interpreta ese mismo saludo como una renegociación de la conexión que había abierto el atacante. Al terminar, el atacante no puede leer el tráfico posterior de la víctima. El fallo no consiste en una transparencia total del cifrado, sino en la atribución: el servidor puede tratar el prefijo del atacante y los datos autenticados de la víctima como un solo intercambio.

RFC 5746 hizo visible una distinción fundamental. La continuidad del transporte, la continuidad criptográfica y la continuidad del transcript de aplicación no son equivalentes. Una misma conexión puede conservar el canal y cambiar de identidad sin decir cómo deben interpretarse los bytes anteriores.

Convertir el pasado en prueba

La solución mantiene tres datos por conexión: una bandera que indica renegociación segura y los valores verify_data que cliente y servidor enviaron en los mensajes Finished del saludo inmediatamente anterior. Esos valores ya prueban que cada extremo vio el transcript previo; reutilizarlos permite identificar de qué historia parte el siguiente saludo.

La extensión renegotiation_info, con tipo 0xff01, está vacía en un saludo inicial. En un ClientHello de renegociación contiene el verify_data anterior del cliente. En el ServerHello contiene el valor del cliente concatenado con el del servidor. Cada extremo compara lo recibido con su propia memoria y aborta si falta la extensión o si no coincide.

El atacante puede transportar el saludo de la víctima, pero no puede hacer que ese saludo contenga la prueba del canal anterior del atacante. La defensa no confía en que el nuevo intercambio vaya cifrado: exige que declare de forma autenticada qué intercambio continúa.

El coste de convivir con sistemas antiguos

Algunos programas antiguos cerraban la conexión al ver extensiones desconocidas, aunque las reglas de TLS exigían ignorarlas. RFC 5746 creó por ello TLS_EMPTY_RENEGOTIATION_INFO_SCSV, una señal colocada entre las suites ofrecidas que no representa ningún algoritmo y nunca puede negociarse. Comunicaba soporte para la reparación con una forma más tolerable para servidores antiguos.

La compatibilidad dejaba un área gris. Un servidor que no reconocía la señal podía ser vulnerable, o podía haber desactivado toda renegociación y ser seguro por otra vía. El cliente no tenía una prueba TLS que distinguiera ambos casos. La transición obligaba a elegir entre rechazar pares inciertos o mantener acceso a sistemas heredados. Así, una propiedad criptográfica terminó dependiendo también de una política explícita sobre la ausencia de evidencia.

De reparar la transición a retirarla

TLS 1.3 no conserva la renegociación general. RFC 8446 prohíbe un ClientHello posterior fuera del flujo esperado y ordena terminar la conexión. La actualización de claves y la autenticación posterior existen como mecanismos separados, con objetivos y límites propios.

RFC 9325 mantiene la obligación para TLS 1.2: clientes y servidores deben implementar renegotiation_info, y el cliente debe terminar si el servidor no la reconoce. Las fuentes no miden cuántos ataques reales ocurrieron ni cuántos servicios actuales aún renegocian. Sí permiten fijar la lección histórica: cuando cambian las claves o la identidad, el protocolo debe probar qué estado anterior hereda. El socket abierto no es esa prueba.

Fuentes