This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author christian.heimes
Recipients alex, christian.heimes, dstufft, janssen, martin.panter, njs
Date 2018-05-18.13:09:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1526648945.1.0.682650639539.issue30437@psf.upfronthosting.co.za>
In-reply-to
Content
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).
History
Date User Action Args
2018-05-18 13:09:05christian.heimessetrecipients: + christian.heimes, janssen, alex, njs, martin.panter, dstufft
2018-05-18 13:09:05christian.heimessetmessageid: <1526648945.1.0.682650639539.issue30437@psf.upfronthosting.co.za>
2018-05-18 13:09:05christian.heimeslinkissue30437 messages
2018-05-18 13:09:04christian.heimescreate