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. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
