On Thu, Nov 19, 2009 at 02:37:28PM +0100, Dr. Stephen Henson wrote: > > > > 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.
Not connections, renegotiation attempts, correct? The initial handshake certainly still seems to succeed. > 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. I think it's a mistake to send a fatal alert. In the past week as I've been experimenting with this, I've encountered a number of embedded client devices (cellphones -- I suspect I know which stack they're using but I'm not certain, so I won't identify the vendor here) which do periodic renegotiations and can't be configured not to. I hacked up no-renegotiation alert for a somewhat simpler TLS implementation since I kept tripping over myself trying to do it with OpenSSL. The result was that these clients could maintain connections -- they ignore the failed renegotiation. With OpenSSL, these clients simply lose their connection and don't display pages. I think this is wrong. It breaks clients which basically cannot be upgraded to exhibit different behavior, and I don't think it actually provides enhanced security: rejecting the new handshake with a warning would thwart the attack too, right? If a client actually initiates a renegotiation, the server certainly appears to be allowed to reject it, by the TLS spec, with the warning alert. If the client really insists on a new handshake, it can close the connection and reopen it. If a client doesn't initiate a renegotiation, but gets an unexpected no renegotiation warning alert from the server, the attack's failed, and the client has been notified as well as we can anyway. This seems a lot better than just dropping the connection in this case, too, since that might happen for any number of reasons. Thor ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
