> On Nov 2, 2022, at 16:36, Michael Wojcik via openssl-users <openssl-users@xxxxxxxxxxx> wrote: > >> From: Felipe Gasper <felipe@xxxxxxxxxxxxxxxx> >> Sent: Wednesday, 2 November, 2022 12:46 >> >> I wouldn’t normally expect EPIPE from a read operation. I get why it happens; >> it just seems odd. Given that it’s legitimate for a TLS peer to send the >> close_notify and then immediately do TCP close, it also seems like EPIPE is a >> “fact of life” here. > > Yeah. That's because an OpenSSL "read" operation can do sends under the covers, and an OpenSSL "send" can do receives, in order to satisfy the requirements of TLS. Depending on the TLS version and cipher suite being used, it might need to do that for renegotiation or the like. Or if the socket is non-blocking you can get WANT_READ from a send and WANT_WRITE from a receive. > > In your example it was actually a sendmsg that produced the EPIPE, but within the logical "read" operation. > > The original idea of SSL was "just be a duplex bytestream service for the application", i.e. be socket-like; but that abstraction proved to be rather leaky. Much as sockets themselves are a leaky abstraction once you try to do anything non-trivial. It sounds, then like shutdown() (i.e., TCP half-close) is a no-no during a TLS session. Does OpenSSL’s documentation mention that? (I’m not exhaustively familiar with it, but I don’t remember having seen such.) 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. I don’t recall having seen it in 1.1 or earlier OpenSSLs. Then again, maybe some application wants to know it shouldn’t send a notify-close. It surprises me that notify-close then close() is considered legitimate use. WebSocket and SCTP both have similar shutdown workflows, but I think they expect the peers to await each other’s “farewell” message. -FG
