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 deploymen

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.