Oops. Make that May 2011. Sorry for the typo.

Quoting myself:

Clarification: The reason, why browsers don't warn yet, is that browsers would have to warn very often. Currently there are too few patched servers. According to numbers provided by Yngve Pettersen, in May 2001, about 45% of all servers in total were still unpatched. A frequent warning would likely have the undesired effect to educate users to ignore the warning.

If I understand correctly, your proposal is, when a browser connects to an unpatched server, the browser shouldn't worry until the server requests to renegotiate. You propose, it's fine to wait until this happens, and warn in that situation.

Unfortunately your plan doesn't work. The issue is that a browser cannot detect whether a MITM renegotiated with the server!

Even if a server is configured to allow renegotiation, the ordinary browser visitor might never trigger it, and therefore the browser might never see it happen.

A hacker can either (a) use a client/hacker initiated renegotiation if allowed by the server or (b) probe the server using trial-and-error to find an URL that triggers a server initiated renegotiation. (Even if (a) is disabled, you could still be successul with (b), because server software configuration options may allow both to be enabled or disabled independently.)

Now, if the hacker is able to trigger a renegotiation either way, the renegotiation will be limited (!) to the route between MITM and server!

The browser will not notice! The browser will see only the single initial negotation!

If the browser cannot see the renegotiation, then it cannot warn that it's happening. That's the dilemma!

This is why we must aim to get servers upgraded, so that browsers can start to warn about this risk when dealing with unpatched servers.

For the simpler scenario, where no MITM is present, yes, Firefox 4 and later versions will detect if an unpatched server requests a renegotiation, and abort the connection by default. But I hope I explained it well enough to make it clear, that's not sufficient.

Maybe! But is "maybe" good enough when dealing with security?

All it takes is an IT person who is unaware that renegotiation was disabled for a reason, and now reenables it because of a new business need: the site is vulnerable again.

I don't like the idea that customers have to trust website operators to run with a hotfix and will never reenable the vulnerability accidentally. It's better to know for sure that a site is fixed. Only patched sites can give us this certainty.

The less unpatched servers there are, the sooner browsers can reasonably warn about unpatched servers, and reject connections to unpatched servers by default.

Thanks for pointing this out. Added.

As you can see from the list, Firefox would have to warn quite often. The worry is, if you warn too often, your users will ignore it.

However, you are encouranged to change a preference. Use about:config and change security.ssl.treat_unsafe_negotiation_as_broken to true. This way, when you visit an unpatched site, you'll no longer get good security indicators. If you think this is a good idea, you could vote for this at https://bugzilla.mozilla.org/show_bug.cgi?id=665859 (please use the vote feature, and limit comments to interesting thoughts).

If you want to disable all connections to unpatched sites, you can set security.ssl.require_safe_negotiation to true, but unfortunately, as can be seen from list, you'd lock yourself out of a lot of sites.

Unfortunately, as explained, Firefox cannot easily distinguish between "unpatched and vulnerable" vs. "unpatched but partially hotfixed" vs. "unpatched and completely hotfixed". It's simply not possible when using the old TLS protocol version. Probing the sites would result in a slower experience, and probing cannot produce definitive results anyway.

I believe the right approach would be to present an error page whenever you connect to an unpatched server, but if absolutely desired, allow the user to add an override, similar to what Firefox currently does with sites that use untrusted certficates. The user interface for such a feature has not yet been implemented in Firefox. The discussion is happening in https://bugzilla.mozilla.org/show_bug.cgi?id=535649 - However, as of today, you can manually get a similar experience, by using advanced preferences, combining security.ssl.require_safe_negotiation = true and manually adding override sites to security.ssl.renego_unrestricted_hosts

More detailed explanations can be found at https://wiki.mozilla.org/Security:Renegotiation