[openssl-users] Strange problem with 1.0.2f SSL_shutdown in multithreaded server
matt at openssl.org
Tue Feb 2 11:34:10 UTC 2016
On 02/02/16 11:24, Jakob Bohm wrote:
> On 02/02/2016 11:40, Matt Caswell wrote:
>> On 02/02/16 07:52, Jakob Bohm wrote:
>>> I am trying to upgrade an existing 3rd party multithreaded server
>>> from OpenSSL 1.0.2c to 1.0.2f . However when I do so, it starts
>>> mishandling the close_notify "alert".
>>> 1.0.2f seems to send the close_notify alert unencrypted followed
>>> by an encrypted decrypt_failed alert, where 1.0.2c correctly
>>> sends just an encrypted close_notify alert.
>>> I am unsure if this exposed a bug in the daemon or in OpenSSL
>> I have a theory.
>> Previous versions of 1.0.2 handled an SSL_shutdown() call while in the
>> middle of a handshake by ignoring it and returning 1 immediately
>> (meaning everything shutdown successfully). Clearly everything did not
>> shutdown successfully so the return value is not correct.
> No, actual application data (just a few bytes) was sent in each
> Specifically, some bytes were sent client to server, then a reply
> was sent server to client and the connection was closed.
> Also, the s_client output showed a completed handshake, with
> ChangeCipherSpec in both directions and dump of certificate
> chain before the first application data was sent (client to
> server, then server to client).
> The s_client command line was
> cat data | openssl s_client -connect xx.xx.xx.xx:xxxx -msg -tls1
> -ign_eof -debug
> However I cannot rule out that the changes to either SSL_shutdown()
> or the rearranged error checking code triggered the issue.
Hmmm. Perhaps try reverting the SSL_shutdown() change to rule that out
as related in some way? Patch attached to revert that change back to the
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4187 bytes
Desc: not available
More information about the openssl-users