On Thu, Nov 19, 2009, Thor Lancelot Simon wrote: > On Thu, Nov 19, 2009 at 02:04:43PM +0100, Dr. Stephen Henson wrote: > > > > The version which was in 0.9.8-stable was buggy: OpenSSL tried to do an > > SSLv2 > > compatible client hello and failed because that couldn't negotiate secure > > renegotiation (there is no way to do that because SSLv2 compatible client > > hellos don't support extensions). The result was you'd get s_server/s_client > > not connecting with default options. You needed -legacy_renegotiation to get > > that to work. > > That's annoying, but it seems like a simple enough bug. I am more curious > about why legacy renegotiation is rejected with a fatal invalid parameter > alert instead of what seems to be the correct warning (nonfatal) > no renegotiation alert. Is there a reason why that is the right way, > which I'm just missing? >
The current default behaviour of OpenSSL in 0.9.8-stable is to be "strict", that is it will reject connections from legacy servers/clients. The specification doesn't actually indicate what alert should be used under those circumstances and (I didn't write the initial code) invalid parameter was the most convenient to use at the time (that's what an extension error normally returns). In the strict case a fatal alert is the most appropriate IMHO though which one may be clarified in future versions of the spec. In the lenient case (that is tolerate connections with legacy servers/clients) an alert isn't necessary at all because both sides will know (due to extensioni presence) whether secure renegotiation is permitted. In the actual attack btw the client doesn't see any renegotiation at all: just the server. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
