[issue30437] SSL_shutdown needs SSL_read() until SSL_ERROR_ZERO_RETURN

[Christian Heimes]

Christian Heimes <lists at cheimes.de> added the comment:

The issue can occur when the peer sends data while processing the close notify alert.

The meaningless SSL_ERROR_SYSCALL in SSL_shutdown() is even more severe with OpenSSL 1.1.1 and TLS 1.3. In case the client only writes and never reads, SSL_shutdown fails to unwrap the socket. The issue is caused by the fact that the session ticket is transferred after the handshake. With a SSL_read(), the ticket is stuck on the wire and may not be consumed until OpenSSL waits for close notify TLS alert.

In https://github.com/openssl/openssl/issues/6262#issuecomment-389987860 Kurt wrote:

> The peer is still allowed to send data after receiving the "close notify" event. If the peer did send data it need to be processed by calling SSL_read() before calling SSL_shutdown() a second time. SSL_read() will indicate the end of the peer data by returning <= 0 and SSL_get_error() returning SSL_ERROR_ZERO_RETURN. It is recommended to call SSL_read() between SSL_shutdown() calls.

I hacked SSL_read() into the code and the problem did no longer occur for me. My workaround is not a proper solution, though. The shutdown code is slightly complicated (to say the least).

----------
priority: normal -> deferred blocker
title: SSL_shutdown can return meaningless SSL_ERROR_SYSCALL -> SSL_shutdown needs SSL_read() until SSL_ERROR_ZERO_RETURN
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30437>
_______________________________________