Hi Darryl, As you suspect we don't really need guaranteed secure stream termination, so really all I was interested in was closing the socket cleanly.
I also suspected an application programming error on my part, but I really couldn't track it down, and as I say using the same method that Stunnel uses (the set_shutdown/free) just 'fixed it'. You're almost certainly right, the set_shutdown() is probably redundant, except I think in the case of caching connection attempts (my understanding is this will say 'Yes, we cleanly shut down, so store this connection in the cache'. We're not actually using the connection cache (apologies if I'm using the wrong terminology, I'm rusty on this code now!). So really, I'm now happy with what we're doing to close sockets, and all I can say is I wish I had time to get a replicable test case for this (which in doing so might show me the application error I've made, if any). My contract is up here soon, and once I'm between contracts I might be able to knock something up! Thanks for the reply, Warm regards, Matt ---- Contract Coder, PKR -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darryl L. Miles via RT Sent: 23 June 2006 17:24 To: Matt Godbolt Cc: openssl-dev@openssl.org Subject: [openssl.org #1328] FW: (Repost) SSL_shutdown and SSL_free issues Hello Matt, I am interested in your issue with: SSL_shutdown(ssl); SSL_free(ssl); causing disruption of other SSL connections open within the same application. There should be nothing wrong not checking the return values of SSL_shutdown() is your application does not need a guaranteed end of session and doesn't need to ensure the SSL session cache keeps the session-id around to be re-used again. A guaranteed end of session are for applications that must ensure (cryptographically / securely) that all the data the other end was going to send has been received, and allows your end to signal to the other end its not going to send any more data. This is what the SSL_shutdown() provides, a secure end of transmission indication. This is to stop an attacker from prematurely terminating a network connection (man in the middle) to make each end presume the other end had finished. Most applications dont need this facility. The two calls above like that, would make the SSL_shutdown() attempt to send the shutdown notify alert, which may or may not get commited from application into kernel buffer (to be sent to your peer). You then SSL_free() and presumably a close(fd) takes place. I am thinking your SSL_ERROR_SSL on an SSL_read() of a different (SSL *) is an application programming error. Maybe you can indicate how many other SSL connections the application had open at the time, the amount of throughput/data traffic it was doing, the amount of time a connection stayed open. If you are using: SSL_set_shutdown(c->ssl, SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN); SSL_free(c->ssl); I belive the SSL_set_shutdown() call is redundant in that situation. Since SSL_free() does not initiate an automatic shutdown it just tears down the resources for the SSL socket and you can do no futher work with it. AFAIK SSL_free() will not cause a read() or write() to take place. Best Regards, Darryl -- Darryl L. Miles ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
