[Pkg-bazaar-maint] [Pkg-openssl-devel] Processed: Merge duplicates
kurt at roeckx.be
Sun Apr 12 12:35:52 BST 2020
On Sun, Apr 12, 2020 at 01:06:53PM +0300, Adrian Bunk wrote:
> Some/All? of the 1.1.1e breakage was caused by Kurt changing the
> documentation of an existing function:
> People coded according to the current documentation,
> and then OpenSSL broke it in a stable point release.
You seem to be misunderstanding the problem. The documentation can
probably be improved.
There are some valid ways to terminate an SSL connection:
1) The protocol on top of TLS knows when it's terminated or not,
close notify is not need.
a) Both sides don't a close notify, don't expect it from the
b) Both sides send a close notify, don't expect it from the
2) The protocol on top of TLS doesn't know when it's terminated,
at least one side will need to send close notify.
a) The peer that needs to send the close notify sends it,
the other waits for it.
b) Both sides send a close notify, both sides wait for it.
The problem is that there are some other variations that cause
problems. For instance in the case of 1), if one sides doesn't
sent it, but the other expects it, you will get an error. The same
goes for 2), where it might not be needed for both to send it,
only 1 sends it and both expect it.
You always got that error, it was just a different error. And you
get that error using both SSL_read() and SSL_shutdown().
The fix is to not call SSL_read() or SSL_shutdown() when you don't
need to do it. This was always the case. But some people just
decided to ignore the error, and have a problem when OpenSSL gave
a different error.
It can also be fixed on the other side by always sending the close
notify, even when not needed.
TLS 1.3 complicates things a little. Session tickets are not part
of the handshake any more and can be send at any time. If you want
to be able to process the session ticket so that you can resume, you
might need to wait for the close notify.
More information about the Pkg-bazaar-maint