Summary

  • A transport close can end a byte stream without proving that every TLS record the peer meant to send arrived. close_notify put a protected, directional no-more-data statement inside TLS.
  • TLS 1.3 stopped treating closure as an immediate full-duplex shutdown. The alert ends one write direction; HTTP length, chunk and stream markers still decide whether an application message is complete.

The last byte was not the last fact

Imagine a response that reaches a receiver and then stops. Every received TLS record passes authentication. The socket reports EOF. Those facts prove that the prefix was protected and that the transport ended. They do not prove that the prefix was the whole answer.

The difference matters most when the application has no independent terminator. If an HTTP response promised 10,000 octets and only 9,996 arrived, the length exposes the loss. If a chunked response lacks its final zero-sized chunk, the grammar exposes it again. A response delimited only by connection closure has no such witness. A clean end and a missing suffix look alike unless the protected protocol says which occurred.

TLS 1.0 named the risk plainly: client and server needed shared knowledge that the connection was ending in order to avoid truncation. Its answer was the close_notify alert. The sender placed a statement inside TLS that it would send no more messages on that connection. Records arriving after the alert were to be ignored.

This did not turn TLS into a document format. It established a boundary that TLS could own: no more protected messages from this sender. The application still had to know whether the records it received contained a complete response, file, command or transaction.

TLS 1.0 attached closure to future trust

The first rule carried a strong operational consequence. If a TLS 1.0 connection ended without proper closure alerts, the session became unresumable. The next connection could not reuse that session state.

That linked two ideas: an unproved ending on one connection and permission to continue an earlier cryptographic relationship later. It was a conservative design. A peer that had not completed the closing exchange lost the shortcut of resumption.

Practice pushed back. TLS 1.2 records that TLS 1.1 had removed the automatic no-resumption consequence to conform with widespread implementation behavior. The alert obligation remained, but one missing close exchange no longer invalidated the resumability of the session by itself.

The change is revealing. The specification kept the semantic boundary while relaxing a punishment that deployment had not sustained. Closure evidence and resumption policy were related, but they did not need to be the same decision.

The old reply rule could cut the other direction

Before TLS 1.3, receiving close_notify carried an immediate reciprocal duty. The peer was required to send its own alert, close down the connection and discard pending writes. The initiator did not need to wait for that reply before closing its read side.

That rule made closure look symmetrical even when the application was not finished symmetrically. One endpoint could be done sending while still expecting a final response. If the receiver of the first alert discarded pending writes, the closure mechanism intended to resist truncation could itself truncate the reverse direction.

TLS 1.3 repaired the model by treating close_notify as orderly closure of one direction. Sending it closes the sender's write side; it does not close the read side. The peer no longer has to discard pending reverse writes or answer immediately. Each direction can finish when the application using that direction is actually done.

The standard also states the residual uncertainty with unusual precision. If a transport-level close arrives before close_notify, the receiver cannot know that all data sent by the peer was received. Earlier authenticated records are not retroactively corrupted. What remains uncertain is the missing future: records that may have existed after the last one observed.

HTTP supplied the boundary TLS could not see

HTTP over TLS separated cryptographic integrity from message completeness. A premature close did not call received data insecure; it meant later data might have been truncated. Because TLS could not see HTTP request and response boundaries, the client had to examine HTTP framing.

The modern HTTP/1.1 specification keeps that division. A declared Content-Length is evidence when exactly that many octets arrive. Chunked coding has a terminal zero-sized chunk. If either boundary is missing, the message is incomplete. A close-delimited response, however, is complete over TLS only after a valid closure alert; otherwise accepting the prefix as final can expose the implementation to attack.

This makes close_notify neither universal nor redundant. It is decisive where closure is the message delimiter. Where the application has already proved completion, an incomplete TLS close can be classified without pretending that the completed message lost integrity. The application, not the transport library alone, owns that distinction.

HTTP/2 made the layering easier to observe. In RFC 9113, END_STREAM closes one HTTP stream direction while other streams can continue on the same connection. It is application-stream finality, not TLS-connection finality. A stream can therefore prove its own end before the shared TLS channel later performs its separate closure.

One alert, one claim

close_notify does not authenticate a person, authorize a transaction, confirm that an application consumed data or certify that every higher-layer message was complete. It makes one bounded statement: the sender will send no more TLS messages in that direction.

That modest scope is why the mechanism endures. A bare EOF is an event. A protected closure alert is evidence about intent. A Content-Length, chunk terminator or END_STREAM is evidence about application structure. Reliable systems keep those facts separate and combine them only when their scopes align.

Sources and limits

The account uses RFC 2246, RFC 2818, RFC 5246, RFC 8446, RFC 9112 and RFC 9113. They define protocol behavior and historical changes, not current library defaults, deployment share or the cause of any observed missing alert.