> From: Felipe Gasper <fel...@felipegasper.com>
> Sent: Thursday, 3 November, 2022 07:42
> It sounds, then like shutdown() (i.e., TCP half-close) is a no-no during a
> TLS session.

Um, maybe. Might generally be OK in practice, particularly with TLSv1.3, which 
got rid of some of the less-well-considered ideas of earlier TLS versions. 
Honestly I'd have to spend some time digging through chapter & verse of the 
RFCs to arrive at any reliable opinion on the matter, though. Someone else here 
may have already considered it.

> Does OpenSSL’s documentation mention that? (I’m not exhaustively
> familiar with it, but I don’t remember having seen such.)

I doubt it. I don't see anything on the wiki, and this is a pretty obscure 
issue, all things considered.

> It almost seems like, given that TLS notify-close then TCP close() (i.e.,
> without awaiting the peer’s TLS notify-close) is legitimate, OpenSSL could
> gainfully tolerate/hide the EPIPE that that close() likely produces, and have
> SSL_read() et al just return empty-string.

Well, it could, but OpenSSL generally doesn't try to provide that type of 

Also note this paragraph from the wiki page on TLSv1.3 

   If a client sends it's [sic] data and directly sends the close
   notify request and closes the connection, the server will still
   try to send tickets if configured to do so. Since the connection
   is already closed by the client, this might result in a write
   error and receiving the SIGPIPE signal. The write error will be
   ignored if it's a session ticket. But server applications can
   still get SIGPIPE they didn't get before.

So session tickets can also be a source of EPIPE when a client closes the 

> It surprises me that notify-close then close() is considered legitimate use.

There are so many TLS implementations and TLS-using applications out there that 
interoperability would be hugely compromised if we didn't allow a large helping 
of Postel's Interoperability Principle. So most applications try to be 
accommodating. There's even an OpenSSL flag to ignore the case where a peer 
closes without sending a close-notify, in case you run into one of those and 
want to suppress the error.

Michael Wojcik

Reply via email to