Resumen

  • Finished demuestra el transcript del handshake actual bajo el secreto negociado; no incorpora por ello los datos de aplicación enviados antes de una renegociación.
  • RFC 5746 enlaza la nueva negociación con los verify_data anteriores. Todavía hacen falta recibos para cambio de principal, límite de mensaje, autorización, confirmación y efecto externo.

Dos verdades que no formaban una historia

El primer canal TLS ya transporta datos. Llega otro ClientHello, se negocian claves, quizá aparece un certificado de cliente y el segundo Finished pasa la verificación. La biblioteca registra éxito.

En RFC 5246, verify_data deriva del secreto maestro y de los mensajes del handshake. Ese cálculo permite detectar discrepancias en la negociación y confirma que ambos extremos comparten el nuevo estado. Los bytes de la aplicación quedan fuera del transcript.

Antes de la reparación, la nueva prueba tampoco se enlazaba criptográficamente con la conexión anterior. Un intermediario podía abrir una conexión al servidor, aportar un prefijo de aplicación y hacer que el nuevo handshake autenticado de otra parte continuara dentro de ella. El servidor podía ensamblar ambos trozos como una petición. El segundo handshake era válido; la conversación atribuida no lo era.

El mismo socket puede albergar otra autoridad

TLS 1.2 prepara un estado pendiente y mantiene el estado actual hasta ChangeCipherSpec. Después, Finished viaja protegido con el estado nuevo. La transición define qué claves protegen los registros posteriores.

No define qué hacer con una petición que empezó antes. Un parser puede conservar media cabecera o media orden mientras cambia el principal. La aplicación que solo recibe el estado final «cliente autenticado» puede aplicar esa identidad nueva a trabajo almacenado bajo la anterior.

El descriptor de conexión es continuidad de transporte, no continuidad de autoridad. Para gobernarlo se necesita una generación de seguridad asociada a los rangos de bytes y a cada mensaje completo.

RFC 5746 convierte continuidad en una comprobación

Secure Renegotiation introduce renegotiation_info y TLS_EMPTY_RENEGOTIATION_INFO_SCSV. En el handshake inicial, los extremos anuncian soporte y usan un valor de conexión renegociada vacío. En un handshake posterior, la extensión transporta los verify_data Finished previos del cliente y el servidor.

La negociación nueva debe conocer la salida de la anterior. Si los valores no corresponden a esa conexión, el extremo rechaza la renegociación. El vínculo ya no depende de que dos handshakes compartan socket: depende de una relación criptográfica verificable.

No obstante, el registro de una extensión no demuestra una ejecución. Hay que separar biblioteca compatible, política cargada, señal observada, respuesta del par, segundo handshake y comparación correcta de los valores anteriores.

Una costura segura no decide el dueño de la petición

El protocolo reparado no dice si una orden iniciada de forma anónima puede terminar bajo un certificado obtenido después. Puede ser correcto descartar el buffer, finalizar bajo el principal viejo o exigir una orden nueva. Esa es una decisión local de autorización y encuadre.

Las aplicaciones que usan channel bindings de RFC 5929 ganan otra herramienta para enlazar su autenticación con propiedades del canal. Pero producir el binding no acredita que el protocolo superior lo incluyera, verificara y aplicara en la operación concreta.

El modelo prudente entrega al servicio principal, generación TLS, límites de mensaje y decisión de transición. Si falta alguno, no se infiere permiso a partir de Finished.

EMS enlaza otro par de objetos

Extended Master Secret, RFC 7627, deriva el secreto maestro de un hash del transcript y responde a problemas de session hash y triple handshake. No reemplaza el enlace de RFC 5746.

EMS relaciona el secreto con su negociación. Secure Renegotiation relaciona la negociación nueva con la conexión anterior. Un único indicador «TLS reforzado» oculta cuál de esas dos relaciones se verificó.

La auditoría debe conservar por separado EMS, soporte y uso de Secure Renegotiation, valores de enlace, ruta de certificado y principal generado. El detalle no es burocracia: permite localizar la costura que falló.

Quitar la renegociación no prueba haber migrado

TLS 1.3 eliminó la renegociación. Así desaparece este segundo handshake dentro del canal. Pero habilitar TLS 1.3 no demuestra que todos los listeners, proxies y dependencias hayan dejado TLS 1.2. RFC 9851 congela el trabajo ordinario de nuevas funciones en TLS 1.2; no apaga procesos.

Una migración demostrable requiere inventario, configuración efectiva, negociaciones observadas, propietario de cada dependencia y canarios de servicio. Un proxy puede mostrar TLS 1.3 al cliente y mantener TLS 1.2 hacia el origen.

Mientras quede renegociación, conviene guardar una secuencia: handshake y Finished iniciales; bytes de esa generación; disparador; señal segura; comparación; nueva identidad; activación; Finished nuevo; mapeo de principal; límite de petición; autorización; commit y resultado.

Esta secuencia es análisis operativo de BTW, no un formato exigido por RFC 5246. Su propósito es evitar que un recibo criptográfico fuerte se convierta en permiso para una acción que nunca observó.

Fuentes