Summary

  • In RFC 9846, close_notify orderly closes one TLS sending direction and gives the receiver a cryptographic truncation boundary. It does not acknowledge application parsing, durable persistence, side effects or settlement.
  • A sound closure record joins the last accepted TLS record and alert to a separate application transaction identifier, outcome and retry rule. One must never be inferred from the other merely because they are adjacent in time.

Consider a payment client that writes an instruction, flushes its buffer and receives the server’s close_notify. Its TLS library reports end-of-data without a protocol error. If the client stores “paid” at that moment, what exactly supplied the evidence? Not the close alert. The server might have read the bytes but rejected the instruction, parsed it but failed before commit, committed it but lost the response, or closed a direction while continuing to read on the other. Each case is compatible with facts that the transport alone cannot separate.

RFC 9846, the July 2026 Proposed Standard for TLS 1.3, gives close_notify a precise job. It is an orderly closure alert for one direction of the connection. The sender uses it to say that it will send no more messages on that connection. Once the recipient has received it, later data must be ignored, and the TLS implementation should indicate end-of-data to the application.

The phrase “one direction” carries most of the operational meaning. Either party may close its write side with close_notify; doing so does not close its read side. The client can finish sending and continue reading. The server can finish sending while still receiving. TLS 1.3 deliberately does not turn one alert into an immediate symmetric teardown.

Every party must send close_notify before closing its own write side unless it has already sent an error alert. But neither party has to wait for the other’s alert before closing its read side. The RFC warns that closing without waiting can introduce truncation. Two independently controlled directions therefore produce two closure events, not a distributed commit vote.

The alert exists to defend a channel boundary. If an underlying transport close arrives before close_notify, the receiver cannot know that it received all the data the sender sent. An authenticated closure alert distinguishes an orderly end from an unexplained loss of the byte stream’s tail. That is valuable evidence. It still does not reveal what the receiving application did with bytes delivered before the boundary.

The IANA TLS parameters registry assigns the alert description code for close_notify. RFC 9846 restores the requirement to send it with the legacy warning level. The alert is not an error alert merely because it lives in the alert protocol. Error alerts describe abortive closure, prevent further data and trigger different state handling.

The restored warning label also does not mean “optional.” Severity and sending requirement answer different questions. An implementation normally must send the orderly alert before closing its write side. Calling it a warning cannot turn that protocol obligation into an advisory business event, just as code-point registration cannot make it proof of a remote database state.

TLS 1.3 corrected a damaging older reaction pattern. Earlier versions required the receiver of close_notify to discard pending writes, answer immediately with its own alert and close. That could truncate the receiver’s sending direction. The current rule leaves the read and write sides independent, allowing an application profile to finish relevant output instead of treating peer closure as a command to abandon it.

An application may choose to flush its send buffer and immediately answer when it receives close_notify. RFC 9846 cautions that an attacker can influence what the peer receives by delaying the alert or delaying transport delivery of the application’s packets. The application therefore needs its own rule: for example, ignore new application input after it has sent closure, or require a completed application response before deciding the operation’s state.

This is the difference between delivery ordering and effect authority. TLS protects records and supplies an authenticated end to their sequence. A reliable ordered transport supports the assumption that closing the write side delivers pending data before destroying the transport. Neither layer defines the application parser, validates a transaction identifier, allocates an idempotency key, commits storage or emits a durable receipt.

RFC 9293 supplies the TCP model beneath many TLS connections, including independently closing a sending side. RFC 9110 and RFC 9112 define HTTP semantics and HTTP/1.1 message framing above it. These layers can be composed, but composition does not erase their separate completion conditions.

For an HTTP transaction, the useful evidence might be a final response associated with the request, a complete message body under the applicable framing, and application-specific status semantics. For a queue, it might be a broker acknowledgement after durable placement. For a payment, it might be a domain receipt with a stable operation identifier. None is supplied by the two bytes of an orderly TLS alert.

The distinction works in the other direction too. Missing close_notify is not proof that an application operation failed. The application might already have committed and returned a receipt before the transport disappeared. What is missing is the TLS truncation assurance for that direction. A retry policy that turns every missing alert into a replay can duplicate a non-idempotent effect.

user_canceled does not rescue the interpretation. RFC 9846 uses that alert for a handshake cancellation unrelated to protocol failure. It must be followed by close_notify, and receivers should continue reading until closure. After the handshake, ordinary closure is more appropriate. These signals describe TLS state; they do not encode refund, order cancellation or withdrawal of application consent.

The standard also reserves authority to the usage profile. If an application protocol permits bytes on the same underlying transport after TLS has closed, the TLS implementation must receive close_notify before telling the application that TLS data ended. More broadly, RFC 9846 says it does not dictate how a TLS usage profile manages its data transport or when connections open and close.

That boundary prevents overgeneralization. RFC 9001 uses TLS to secure QUIC’s handshake but replaces TLS record protection and its KeyUpdate message, while QUIC has its own connection-closing machinery. RFC 9147 gives DTLS its datagram-specific behavior. A control designed around an ordered TLS stream cannot simply label every encrypted transport close the same way.

Identity remains separate as well. RFC 9525 explains how application protocols bind service identity verification to TLS. That work occurs at establishment and under the application’s usage rules. An orderly close does not reauthenticate either party, extend an authorization lease, confirm the human actor or approve a final side effect.

Operationally, three timestamps often appear close together: the last application write, the last accepted TLS record and the closure alert. Temporal proximity can support investigation, but it cannot substitute for a causal receipt. A server can send closure after it has queued work, before the worker commits it, or after it decided never to perform it. Only the application knows which state is authoritative.

Sources