[openssl-users] Strange problem with 1.0.2f SSL_shutdown in multithreaded server

[Matt Caswell]

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
>>> itself.
>> 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
> direction.
> 
> 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
previous implementation.

Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: revert-shutdown.patch
Type: text/x-patch
Size: 4187 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160202/18e8002a/attachment.bin>