The downgrade is done outside the SSL/TLS protocol, by browser vendors (sorry, I should've made it clear that that point was constrained to real-world deployments of HTTPS, rather than a property of the protocol itself).

Browsers will start by sending a TLS1.something handshake. If that connection fails (due to a TLS alert, or TCP RST) then the browser starts the whole connection again with SSL3. This is to work around broken network appliances (of the sort made by Bluecoat and others) which cannot handle modern versions of TLS.

The only browser which has an effective countermeasure against this is Opera. CURL also does the right thing. I believe HSTS in Chrome also turns off this downgrade behaviour for hosts opting into HSTS.

I while back I surveyed the top 500 (Alexa) web sites, emulating the TLS behaviour of Chrome. Of the 321 sites supporting both SSL3 and TLS1, 86 (27%) chose different security parameters under downgrade conditions. Of these downgrades, 70 (81%) represented attacker-controlled loss of forward secrecy.

> Of the 321 sites supporting both SSL3 and TLS1, 86 (27%) chose different security parameters under downgrade conditions. Of these downgrades, 70 (81%) represented attacker-controlled loss of forward secrecy.

So this is the real problem - a minority of servers are misconfigured and won't use a cipher with forward secrecy under SSLv3. I just checked www.cloudflare.com and www.google.com and both use ECDHE even under SSLv3.

It would be really dangerous if browsers were willing to downgrade to SSLv2, which has no protection of handshake traffic, but SSLv2 has been disabled by default in browsers for years (Firefox even removed support for it altogether in FF8).