> On Nov 2, 2022, at 16:36, Michael Wojcik via openssl-users
> <openssl-users@openssl.org> wrote:
>
>> From: Felipe Gasper <fel...@felipegasper.com>
>> 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
