> On Oct 26, 2022, at 13:34, Michael Wojcik via openssl-users <openssl-users@xxxxxxxxxxx> wrote:
>
>> From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of Felipe
>> Gasper
>> Sent: Wednesday, 26 October, 2022 11:15
>>
>> I’m seeing that OpenSSL 3, when it reads empty on a socket, sends some
>> sort of response, e.g.:
>>
>> ----- before read
>> [pid 42417] read(7<UNIX:[276782->276781]>, "", 5) = 0
>> [pid 42417] sendmsg(7<UNIX:[276782->276781]>, {msg_name=NULL, msg_namelen=0,
>> msg_iov=[{iov_base="\0022", iov_len=2}], msg_iovlen=1,
>> msg_control=[{cmsg_len=17, cmsg_level=SOL_TLS, cmsg_type=0x1}],
>> msg_controllen=17, msg_flags=0}, 0) = -1 EPIPE (Broken pipe)
>> ----- after read
>>
>> What is that being sent after the read()? Is there a way to disable
>> it?
>
> I'd guess it's a TLS Alert Close_notify.
>
> When read/recv on a TCP stream socket returns 0, it means a TCP FIN has been received from the peer (or possibly some interfering middleman, such as a firewall). This indicates the peer will no longer be sending any application data, only at most ACKs and perhaps a RST if conversation does not go quietly into that good night. Since TLS requires bidirectional communications, that means the TLS conversation is effectively open, and the local end needs to be closed; and TLS requires sending a close_notify so the peer knows the conversation has not been truncated.
>
> Now, the most common cause of a FIN is the peer calling close(), which means it can't receive that close_notify. But TCP supports half-close, and the peer *could have* called shutdown(, SD_SEND), indicating that it was done sending but still wanted to be able to receive data. So the local side has no way of knowing, at the point where it gets a 0 from read(), that the peer definitely can't see the close_notify; and thus it's still obligated by the TLS specification (I believe) to send it.
>
> At any rate, that's my understanding of the requirement for sending close_notify - I haven't confirmed that in the RFC - and what I suspect OpenSSL is doing there. I could well be wrong.
>
> If the peer *has* called close, then EPIPE is what you'd expect. Note that on UNIXy systems this means you should have set the disposition of SIGPIPE to SIG_IGN to avoid being signaled, but all well-written UNIX programs should do that anyway. (SIGPIPE, as Dennis Ritchie noted many years ago, was always intended as a failsafe for poorly-written programs that fail to check for errors when writing.)
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.
-FG
