On 2025/05/21 3:59 PM, David Benjamin wrote:
This leads to an interesting interaction with TCP resets and more
simplistic application protocols. Suppose you have a very, very simple
protocol that sends a single request and response pair. (E.g. HTTP/1.x
without connection reuse.)
1.
Client sends request
2.
Server reads request
3.
Server sends response
4.
Server closes connection
Bad programming.
The server should not close the TCP connection immediately, precisely
because there is an intermediate layer of protocol, TLS.
It should instead tell the TLS layer that it will be *sending* no
further data, and then wait around until it gets an indication of
TLS-level close (handling any spurious client data received in the
meantime). Only after that TLS-close indication should it close the
socket.
Now, the two major TLS libraries I know of (OpenSSL, GnuTLS) offer
that "tell the TLS lyer to close" operation directly in terms of
"send a TLS Close Alert" (which is a channel half-close; translating
as "I will send no more". Sending one does not inhibit reception of
data) - and it is reasonable to follow that with a TCP-level half-close,
by the application calling shutdown(SHUT_WR). They can even go in
the same TCP segment (by playing with corking).
[ High-rate server applications might consider pausing before
getting a FIN sent, so that clients get the TIME_WAIT state ]
But being eager with a close() syscall is just wrong.
--
Cheers,
Jeremy
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
