Shouldn't we handle the close_notify here as well?

Thank you for the review, @errorxyz!

I don’t think close_notify should be handled within the send_data() context. This block (except (SSL.ZeroReturnError, SSL.SysCallError)) is meant to catch cases where the peer unexpectedly closes the connection or a transmission error occurs.

Since send_data() is part of the active write phase, inserting a close_notify alert here would violate the TLS state machine — alerts must only be sent after the final successful SSL_write, as per RFC 8446.

In TLS 1.3, it is valid for the peer not to send a close_notify. We detect that on the read side via SSL.ZeroReturnError, and the recent changes explicitly track this in self.peer_sent_close_notify. If no alert is received, we synthesize one during send_close() to maintain spec compliance. So, I think no additional handling is needed in send_data().

alerts must only be sent after the final successful SSL_write, as per RFC 8446.

I can't seem to find this specified in the RFC. Can you please provide a reference?

Also, as per section 6.1,

Note that this is a change from versions of TLS prior to TLS 1.3 in
which implementations were required to react to a "close_notify" by
discarding pending writes and sending an immediate "close_notify"
alert of their own.

we should be immediately sending a close_notify for TLS < 1.3.

Yes, you're right, thanks @errorxyz !

Updated: we now handle close_notify on ZeroReturnError in the send_data function for TLS < 1.3.