Hi,
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)
