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>
