On 2009-11-30 10:50 PST, Rob Crittenden wrote: > I'm considering how to handle SSL re-negotiation in the Apache NSS > provider mod_nss to handle the SSL client-initiated handshake bug.
I hope you realize that there's no difference in vulnerability between client initiated and server initiated renegotiation. A server that participates in renegotiation with SSL 3.x (including TLS) today is vulnerable, regardless of who initiates it. Today, the only way for a server to be invulnerable is to NOT do renegotiation at all. Soon (hopefully) the IETF TLS working group will adopt a modification to TLS (and maybe SSL 3.0 also, although that was never an IETF-specified protocol in the first place). When that has been published, and implemented in most of the SSL/TLS protocol stacks on the Internet, then renegotiation will (once again) be possible to be done safely. However, it is possible that safe renegotiation will ONLY be possible with TLS, and not with SSL 3.0. Servers will have a way of saying "I've been modified so that I never do unsafe renegotiation", even if they never do renegotiation at all, I believe. > When I create a socket I'll set the handshake callback to > InitialHandshakeCallback(). Once the initial SSL handshake is done this > will then reset it to the failure mode, so that if any subsequent > handshaking happens it will fail. Having two separate callback functions is one way to try to address this problem with versions of NSS prior to 3.12.5. But that callback will get called after the handshake is done, and if an MITM attack was being attempted, it may well appear to an outside observer that the attack was successful. You really want to prevent that renegotiation handshake from completing. The handshake completion callback is just too late for that. That's why, in NSS 3.12.5, I added a new SSL socket option to control renegotiation, and set its default to disallow all renegotiation. The default can be changed with an environment variable, or with an API call. The value can also be changed on individual sockets. In NSS 3.12.6 (or some other future NSS release, to follow the publication of the new RFC mentioned above), this socket option will be further enhanced with additional options, and safe renegotiation will become the new default. > The Apache configuration lets one have per-location configuration, for > example requiring SSL client auth only for a subdirectory. To do this it > updates the SSL options on the socket and calls SSL_ReHandshake(). Yes. Other web servers (e.g. Sun, Netscape) do something very similar. But it's equally vulnerable. > What I was thinking about doing here is setting those options, then > setting the callback handler back to InitialHandshakeCallback(). This > should allow the server-initiated handshake to succeed and prevent any > other handshaking (unless we again want to restart it from the server). In the immortal words of Richard M Nixon, "We could do that, but it would be wrong." :) The problem is, a server that does that is just as vulnerable as a server that allows client initiated renegotiation. > Does this (1) seem like a reasonable approach and (2) will it protect > against the client rengotiation issue? No. Sorry. You must disable ALL server renegotiation for a server to be safe, until such time as new safe renegotiation is standardized and deployed. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
