Christian Heimes <li...@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 <rep...@bugs.python.org> <https://bugs.python.org/issue30437> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
