Resumen

  • El cierre del transporte termina un flujo, pero no demuestra que llegaron todos los registros TLS que el par quiso enviar. close_notify añadió una declaración protegida y direccional.
  • TLS 1.3 separó los dos sentidos. La alerta cierra la escritura de quien la envía; la longitud, el chunk terminal o END_STREAM siguen definiendo la integridad del mensaje de aplicación.

El prefijo era auténtico, no necesariamente completo

Una respuesta deja de llegar y el socket entrega EOF. Cada registro recibido supera la autenticación. Eso permite confiar en los bytes presentes y constatar que el transporte terminó. No permite deducir que no existía un sufijo.

La aplicación puede aportar otra frontera. Si Content-Length prometía 10.000 octetos y llegaron 9.996, la carencia es visible. Si falta el chunk cero, el cuerpo chunked no ha terminado. Cuando la propia desconexión delimita la respuesta, una terminación normal y un corte prematuro producen la misma señal exterior.

TLS 1.0 describió el problema como truncamiento. Cliente y servidor debían compartir el conocimiento de que la conexión terminaba. close_notify permitió que un extremo declarase, dentro de TLS, que no enviaría más mensajes. Cualquier dato posterior a esa alerta debía ignorarse.

La afirmación no convertía TLS en formato documental. Solo fijaba la frontera que la capa podía conocer: ha terminado la secuencia protegida de este emisor. La completitud de una respuesta, un archivo o una transacción seguía arriba.

El primer diseño ligó el cierre a la reanudación

En TLS 1.0, una conexión terminada sin alertas correctas volvía la sesión no reanudable. Una clausura sin prueba eliminaba el atajo de retomar el estado criptográfico en la conexión siguiente.

La práctica debilitó esa sanción. TLS 1.2 documenta que TLS 1.1 ya había retirado la prohibición automática de reanudar para ajustarse a la implementación extendida. La obligación de enviar la alerta antes del cierre normal del lado escritor permaneció.

Así se separaron dos decisiones. La falta de una clausura protegida conserva su significado; no necesita decidir por sí sola el futuro de una sesión.

La respuesta inmediata podía mutilar el regreso

Hasta TLS 1.2, quien recibía close_notify debía responder enseguida con su propia alerta, cerrar la conexión y descartar escrituras pendientes. El iniciador podía cerrar su lectura sin esperar esa respuesta.

La aplicación no siempre acaba simétricamente. Un cliente puede haber terminado de enviar y necesitar todavía la respuesta final. Si el servidor elimina su salida pendiente al recibir la alerta, el mecanismo contra el truncamiento trunca el otro sentido.

TLS 1.3 convirtió la alerta en cierre ordenado de una sola dirección. El emisor clausura su escritura, no su lectura. El par puede terminar lo que aún debe enviar y contestar con su alerta cuando su propio sentido esté listo.

La norma conserva una advertencia precisa: si primero llega el cierre del transporte, el receptor no sabe si recibió todo lo enviado. Los registros anteriores no pierden autenticidad. Lo desconocido es el futuro ausente.

HTTP ofrece la frontera que TLS no entiende

HTTP sobre TLS distinguió los datos seguros ya recibidos de los que quizá fueron cortados. TLS ignora las fronteras de petición y respuesta; por eso el cliente debe examinar el encuadre HTTP.

HTTP/1.1 usa varias pruebas. Content-Length cuenta octetos. El coding chunked concluye con un chunk de tamaño cero. Si faltan bytes o terminador, el mensaje queda incompleto. Una respuesta sin ambos mecanismos depende del cierre y solo es completa sobre TLS cuando llega una alerta válida.

De ahí que un cierre incompleto no tenga una política universal. Si ya llegó la longitud exacta, puede estar completo ese mensaje aunque la conexión acabe mal. Si el cierre era la única frontera, aceptar el prefijo puede ser peligroso. La biblioteca TLS no puede decidirlo sin la gramática superior.

HTTP/2 coloca END_STREAM en un flujo concreto. Ese flujo puede cerrarse mientras otros continúan en la misma conexión. Es una prueba de estructura de aplicación, no un reemplazo del cierre TLS del canal compartido.

Una afirmación limitada resulta más fiable

close_notify no autentica personas, no autoriza negocios, no confirma lectura y no certifica todos los mensajes superiores. Afirma que su emisor no añadirá más mensajes TLS en ese sentido.

EOF es un hecho del transporte. La alerta es intención protegida. Longitud, chunk final o END_STREAM son estructura. Mezclarlos bajo una sola palabra, «cerrado», destruye la evidencia que cada capa sí puede ofrecer.

Fuentes y límites

La base es RFC 2246, RFC 2818, RFC 5246, RFC 8446, RFC 9112 y RFC 9113. Define conducta e historia normativa, no despliegue actual, valores por defecto ni la causa de una alerta ausente.