Why is TLS susceptible to protocol downgrade attacks? A recent blog post from Ivan Ristić (expert extraordinaire on all things SSL) says:


  all major browsers are susceptible to protocol downgrade attacks; an active MITM can simulate failure conditions and force all browsers to back off from attempting to negotiate TLS 1.2, making them fall back all the way down to SSL 3. At that point, the predictable IV design is again a problem. Until the protocol downgrade weakness is fixed, newer protocols are going to be useful only against passive attackers, but not against the active ones.


Why is this?  Why is TLS vulnerable to this?

I know that SSL 3 included special mitigations to prevent protocol downgrade attacks where a man-in-the-middle downgraded two SSL3-capable endpoints so they end up using SSL 2.  This protection in SSL 3 was critical, because SSL 2 had some major problems, and if you could downgrade both endpoints to SSL 2, nasty attacks would have become possible.  Happily, the SSL 3 designers anticipated this risk in advance and made sure to introduce a special mechanism in the protocol to prevent "downgrade-to-SSL2" attacks.

So how is it that TLS ended up without any mitigation to prevent downgrade from TLS 1.2 to TLS 1.0 or even to SSL 3.0?  Is there some reason why it is non-trivial to add downgrade protection?  Did the TLS standard committee just overlook this one?  Or, was it considered a low priority?  Is there a straightforward way for future versions of TLS to address this issue?
Short answer: Because the browser developers have long thought interoperability to be more important than security and standard compliance.

Slightly longer answer: Some SSL/TLS server implementations do not negotiate the protocol version correctly, but terminate the connection with a fatal alert if the client attempts to negotiate a protocol version that the server doesn't support. This might happen at either of three steps in the handshake protocol: 


When the server parses the client hello (which should contain the highest protocol version supported by the client). A correctly implemented server should store the client version value, even if it is not supported by the server.
When parsing a client key exchange message containing a RSA encrypted pre master secret (which should contain the highest protocol version supported by the client as the first two octets). This version field should be compared to the client version value above, and not to the negotiated version.
When verifying the client finished message (which should be a hash of all handshake messages, including the client hello which contains the highest protocol version supported by the client).


Now, if the server for some reason doesn't process these steps in accordance with the TLS 1.0, 1.1 or 1.2 standards, but one way or another e.g. requires the highest protocol version supported by the client to have a specific value, or to be no greater than the highest protocol version supported by the server, the client has two choices: Either fail the connection with an error message that is displayed to the user, or attempt to connect again with the highest protocol version disabled.

The exploit is possible if the client uses the second alternative (which e.g. Chrome does, but not IE 10). Even if the authentic server actually supports TLS 1.1 or TLS 1.2 and the authentic server actually does handle the client version value correctly, the MITM might exploit that the client doesn't know which server handles the client correctly or not, and inject alerts in both directions to get the client to reconnect using a lower version.



Edit: For completeness, I should add that I concur with @Thomas in his answer that this should largely be a non-issue, simply because:


Trivially, even under a MITM attack that exploits this behavior, neither the client nor the server will be able to negotiate a protocol version they don't enable, and
Neither the client nor the server should enable protocol versions that don't provide adequate security.


The underlying problem is not really that some clients negotiate the protocol version in a way that is not strictly supported by the standard, in order to be able to connect to servers that might or might not negotiate the protocol version in a way not strictly supported by the standard. 

Rather, the problem might occur in situations where Carol might connect to multiple servers, but TLS 1.2 is only required for the connection to Sue, for all other servers SSL 3.0 is sufficient. Conversely, Sue might accept connections from multiple clients, but it is only the connection from Carol that requires TLS 1.2. Ideally, Carol and Sue should be able to rely on the protocol negotiation to ensure that TLS 1.2 automatically gets negotiated (and in such case they might, or might not, be vulnerable to the exploit), but correct implementations should really check that the TLS connection meets the minimum security requirements after it has been negotiated.