On Fri, May 23, 2025, at 06:17, Jeremy Harris wrote: > Bad programming. I might not have said this, but I was going to say something approximately like what you said afterwards.
I don't think that you can fault the application, but you can interpret the close differently at the TLS layer. That is, as you suggest, that the TLS layer can take the close under advisement and do what is necessary to follow that instruction. Which might involve sticking around long enough to complete the handshake, even if the application doesn't need it. Interestingly, this is exactly what the TCP stack does. David mentioned that a retransmission of already-received data doesn't cause the server to send a RST. Why is that? If the server dropped all state, a PSH really would induce a RST in response. It's because the TCP stack really does maintain some state, so that it can recognize a PSH that can be ignored (one with a sequence number between the initial and final values for the closed connection) from one that does need a RST (one outside of that narrow range). Of course, this presumes a particular architecture, in which the TLS stack is a layer on top of TCP. It's not a model I favor any more. I prefer the SSLEngine one, where TLS is kept to the side, with the application driving the TCP bits. In that case, this gotcha becomes an application problem. Maybe the simple application in the example isn't going to do that, so it's fine to think of this as being strictly layered in software, but it's worth acknowledging our assumptions. _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
