Message317028
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). |
|
Date |
User |
Action |
Args |
2018-05-18 13:09:05 | christian.heimes | set | recipients:
+ christian.heimes, janssen, alex, njs, martin.panter, dstufft |
2018-05-18 13:09:05 | christian.heimes | set | messageid: <1526648945.1.0.682650639539.issue30437@psf.upfronthosting.co.za> |
2018-05-18 13:09:05 | christian.heimes | link | issue30437 messages |
2018-05-18 13:09:04 | christian.heimes | create | |
|