Hi there, Apologies for mailing this to [EMAIL PROTECTED] but I think I have found a bug in OpenSSL, and despite subscribing to openssl-users and posting twice, neither of my posts have made it through. If I can be of any help in looking further into this manner, please let me know.
See attached message for more information on my issue, Warm regards, Matt Godbolt Contract Coder www.PKR.com 4th Floor, 74-80 Camden St London, NW1 0EG T: 0207 874 5319 M: 07971 472137 -----Original Message----- From: Matt Godbolt Sent: 10 May 2006 09:31 To: 'openssl-users@openssl.org' Subject: (Repost) SSL_shutdown and SSL_free issues [apologies if this is a dupe; sent yesterday directly after subscribing to list, and hasn't appeared in either my inbox or on the archive yet, assuming it got lost somewhere!] Hi there, I've been having an issue with OpenSSL which has the hallmarks of either an OpenSSL bug, or a misuse of the code on my part. By comparing my usage of OpenSSL against that of Stunnel, I've been able to trace the area that caused me issues and resolve it, but there may still be an underlying problem. With this in mind I thought it best I speak to you guys in case either it is an OpenSSL bug, or whether I'm just doing something wrong! I'm using OpenSSL to wrap around an existing network library. As best I can tell, I'm doing everything by the manual, using memory BIOs to buffer the non-blocking IO down to the existing network libraries read/write routines, and then using OpenSSL to en/decrypt from those. The issue I had was in the instance where the underlying network library failed, usually as a 'connection refused' type message. In this situation, I was previously (and semi-erroneously) doing: SSL_shutdown(ssl); SSL_free(ssl); Note how I had ignored the fact that SSL_shutdown can require re-running until the shutdown negotiation could fail. I knew that the underlying transport had already long gone, so calling shutdown was a bit of a overzealous thing to do anyway. However, the problem I was getting was if I called SSL_shutdown then SSL_free, *other* SSL sockets that were active at the time would mysteriously fail, returning SSL_ERROR_SSL from SSL_read. I noticed that Stunnel does: SSL_set_shutdown(c->ssl, SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN); SSL_free(c->ssl); under these circumstances, and this is what I'm now doing, which fixes all my issues. However wrong it is to call SSL_shutdown() and then not check the return value, not retrying etc, I don't believe that then subsequently calling SSL_free() on that SSL object should cause problems. Time pressure here has meant I've not been able to get a separate test case of this issue unfortunately. I'd appreciate any comments; has anyone ever seen this issue? A concern is that if an SSL connection is in the process of shutting down (having called SSL_shutdown legitimately) and then the transport fails, then the same sequence of calls to OpenSSL will be given (partial shutdown/free) which could then cause more obscure issues at a later date. I'm using OpenSSL 0.9.8a Thanks in advance for any comments or suggestions, Matt Godbolt Contract Coder www.PKR.com 4th Floor, 74-80 Camden St London, NW1 0EG ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
