Hi, On Tuesday 10 November 2009, Jean-Marc Desperrier wrote: > So when Apache is compiled with openssl 0.9.8l, TLS renegotiation > will be fully disabled. > > But the problem with that if that some comments of the discussion > inside https://issues.apache.org/bugzilla/show_bug.cgi?id=39243 > are true, this change will unexpectedly break very badly a *lot* > of sites. > > Those comments suggest Apache currently requests TLS renegotiation > in quite a few cases where it should not be needed, and where it > won't be expected. > > First there's the short SSLSessionCacheTimeout problem : > https://issues.apache.org/bugzilla/show_bug.cgi?id=39243#c23 > > In my understanding, SSLSessionCacheTimeout should never cause > renegociation. If the client tries to do a SSL session resume, and > the server does not have the SSL info for that SSL id anymore, the > result is a brand new SSL Session, *not* a SSL renegotiation. > > If they actually are resumes caused by SSLSessionCacheTimeout, then > it seems SSLSessionCacheTimeout times out sessions that are > currently active at the TCP level, and where the user is just > trying to send more data. Or there's a bug in the resume code that > first says yes, then finds the session id should have been timed > out, so forces a renegotiation. Anyway, this means this was > already broken in some way before, but it used to be of little > consequences and will now be a huge problem. > > Second there's the SSLVerifyClient optional problem : > https://issues.apache.org/bugzilla/show_bug.cgi?id=39243#c21 > > When SSLVerifyClient optional is actually used to allow various > authentication level, it's expected that the change will break the > site. > > But what this comment report is that simply having SSLVerifyClient > optional set, not having any different value anywhere, not even > *using* client certificates, will cause renegotiation to happen > and therefore sites to break when TLS renegotiation is disabled. > And Peter Gutmann just reported on oss-sec that they are many > servers configured like this (see > http://seclists.org/oss-sec/2009/q4/138 ) with their admin not > even knowing that they require client certificates. > > According to the following comment, it might be that a very simple > patch would correct this problems : > https://issues.apache.org/bugzilla/show_bug.cgi?id=39243#c16 > (I've checked the svn code for apache 2.2.x, that piece of code is > still exactly the same, but I don't understand enough to be sure > that just handling the "optional" case in addition to the "none" > case would really be enough to solve the problem) >
I cannot reproduce the problems. With an openssl that rejects all renegotiations, both reconnections after ssl session timeout and connections to a host with sslverifyclient optional work fine (with openssl s_client). Cheers, Stefan