Resumen

  • Según RFC 9846, close_notify cierra de forma ordenada un sentido de envío TLS y marca un límite contra el truncamiento. No acusa recibo del procesamiento, la persistencia ni el efecto de la aplicación.
  • Un expediente fiable conserva el último registro y la alerta, pero los enlaza con un recibo de aplicación separado que contiene operación, resultado autoritativo e idempotencia.

Un terminal manda una instrucción, vacía su búfer y recibe el cierre ordenado del servidor. La biblioteca entrega fin de datos sin error. Todavía son posibles varios resultados: rechazo antes de analizar, aceptación en memoria, inserción en una cola, confirmación durable o compromiso seguido de pérdida de la respuesta. La alerta TLS no distingue ninguno.

RFC 9846, estándar propuesto de julio de 2026 para TLS 1.3, define close_notify como alerta de cierre ordenado de una dirección. El emisor afirma que no mandará más mensajes en esa conexión. El receptor debe ignorar datos posteriores y la implementación TLS debería indicar fin de datos a la aplicación.

La palabra «dirección» impide interpretar la alerta como cierre total. Cualquiera de las partes puede terminar su lado de escritura sin afectar su lado de lectura. El cliente puede dejar de enviar y seguir esperando; el servidor puede terminar una respuesta y continuar leyendo. Cada extremo controla su propia salida.

Salvo que ya haya enviado una alerta de error, cada parte debe emitir close_notify antes de cerrar su escritura. No está obligada a esperar la alerta del par antes de cerrar la lectura, aunque hacerlo introduce riesgo de truncamiento. Por tanto, dos alertas no forman una aprobación en dos fases; son dos fronteras de envío independientes.

La frontera importa cuando desaparece el transporte. Si el cierre subyacente llega antes de close_notify, el receptor no sabe si recibió todos los datos que el par envió. La alerta autenticada reduce esa incertidumbre sobre la cola de mensajes TLS. No revela qué hizo el programa receptor con los datos que alcanzaron la interfaz.

El registro de parámetros TLS de IANA identifica el código de la alerta. RFC 9846 restaura el nivel histórico warning. Que sea warning no convierte en opcional la obligación ordinaria de enviarla; que esté en el protocolo de alertas tampoco la convierte en error. Las alertas de error son abortivas y prohíben tráfico posterior.

TLS 1.3 separó las direcciones para corregir un problema heredado. En modelos anteriores, quien recibía el cierre debía descartar escrituras pendientes, responder de inmediato y terminar. Esa reacción podía truncar el otro sentido. El perfil actual puede completar su salida conforme a reglas de la aplicación.

Pero la flexibilidad abre una decisión propia. Una aplicación puede vaciar el búfer y responder a close_notify, aunque RFC 9846 advierte que un atacante puede alterar qué recibe el par retrasando la alerta o la entrega de paquetes. La protección adecuada debe expresarse arriba: por ejemplo, dejar de aceptar nuevas órdenes después de iniciar el cierre y exigir una respuesta semántica para las ya enviadas.

La norma presupone que cerrar el lado de escritura entrega de manera fiable los datos pendientes antes de destruir el transporte. Incluso bajo esa presunción, entregar bytes al extremo TLS no equivale a analizarlos, autorizar su contenido o comprometer una base. La cadena de responsabilidad termina en una interfaz distinta.

RFC 9293 describe el flujo ordenado y el cierre direccional de TCP que suele estar debajo. Las RFC 9110 y 9112 definen la semántica y el encuadre de HTTP arriba. Una respuesta HTTP completa aporta una clase de evidencia que el cierre TLS no contiene.

Otros protocolos necesitan sus propios recibos. Una cola confirma después de guardar; un pago aporta un identificador estable; una API puede dar una respuesta final y permitir consultar estado. La alerta no lleva ningún campo que represente esos compromisos. Su proximidad temporal con la última escritura es una pista, no una firma de la transacción.

La ausencia de alerta tampoco demuestra fracaso de negocio. El servicio puede haber comprometido la operación y perder el transporte antes de devolver su recibo. Repetir automáticamente una orden no idempotente porque faltó cierre ordenado puede duplicar el efecto. El estado correcto es «resultado desconocido», no «no ocurrió».

La alerta user_canceled pertenece igualmente al estado TLS. Indica cancelación del saludo por una razón ajena a fallo del protocolo, debe ir seguida de close_notify y no debería interrumpir la lectura antes del cierre. No codifica cancelación de compra, revocación de consentimiento ni reversión de una operación.

RFC 9846 deja el control final al perfil de uso. Si el transporte admite datos no TLS después del cierre, la implementación debe haber recibido la alerta antes de comunicar fin de datos TLS. Aun así, la norma no impone cuándo abre o cierra el transporte una aplicación.

Las diferencias de transporte hacen peligrosa cualquier universalización. RFC 9001 usa TLS para el saludo de QUIC, pero reemplaza su capa de registros y cuenta con cierres QUIC. RFC 9147 adapta TLS al mundo de datagramas. Un mismo nombre operativo no debería ocultar mecanismos diferentes.

Tampoco se renueva la identidad. RFC 9525 sitúa la comprobación de identidad de servicio en la integración entre TLS y el protocolo de aplicación. Una alerta de cierre no repite el saludo, no amplía la autorización ni confirma a la persona que originó el mandato.

Fuentes