Does TLS_FALLBACK_SCSV provide blanket protection against downgrade attacks?

Question

The TLS_FALLBACK_SCSV flag was touted as a way to prevent POODLE, which abused the potential to downgrade to SSLv3 from TLS. Does the implementation of this flag prevent similar downgrade attacks (e.g. FREAK, Logjam) against TLS?

From what I can tell, TLSv1.2 doesn't have export ciphers, so a failure to achieve a downgrade from it (assuming both client and server support it) should prevent export-grade downgrades.

Is my reasoning correct here? Is it a valid protection?

Answer 1

TLS_FALLBACK_SCSV fails to protect against Logjam for the same reason that Logjam actually works. That anti-fallback mechanism relies on the client putting it in the ClientHello, and being ultimately part of the input to the hash function that computes the final Finished message. This works only as long as the active attacker cannot break the handshake crypto immediately, and fix in real-time the Finished message contents. But that is exactly what happens with Logjam: the attacker modifies the ClientHello message to include the export RSA cipher suite as part of the client suites, so that the ClientHello that the server receives is not what the client sends. While he is at it, the attacker can also modify other parts of the ClientHello and the ServerHello that comes back as answer, e.g. to modify the advertised maximum version (from TLS 1.2 down to TLS 1.0) and to remove the TLS_FALLBACK_SCSV.

Things go that way:

• Client sends a ClientHello that says "TLS 1.2, can use DHE-RSA, TLS_FALLBACK_SCSV".
• Attacker changes that into a ClientHello that says "TLS 1.0, can use only DHE-EXPORT-RSA, no TLS_FALLBACK_SCSV".
• Server responds with a ServerHello that says "ok, TLS 1.0, DHE-EXPORT-RSA, no fallback".
• Attacker again changes that into a ServerHello that says "ok, TLS 1.2, DHE-RSA, your anti-fallback was seen and well processed".
• Server sends the export DH parameters, duly signed, with a 512-bit modulus. The attacker let them flow as is to the client.
• The client expects "normal" DH parameters, but they are indistinguishable from "export" DH parameters, except for the modulus size, and the client is totally happy with doing weak DH if the server appears to want to do it (apparently, some Safari versions even agree to use a 16-bit modulus...).
• The handshake continues, using this 512-bit modulus that both client and server agree to use (though one of them thinks of it as "export" and not the other).
• The attacker breaks it right away (thanks to its small size and predictable modulus), and thus obtains the session key that client and server use.
• At the end of the handshake, both client and server computes the Finished messages that they should send and that they should receive. They saw distinct handshake messages (the attacker modified the ClientHello and the ServerHello) but the attacker has, at that point, the encryption and MAC keys, so he can decrypt, patch and re-encrypt the Finished messages at will to maintain the illusion.

Summary: TLS_FALLBACK_SCSV is an "anti-downgrade" mechanism, but it covers only the protocol version, and, more importantly, it works only as long as the downgraded handshake is still resilient to immediate and total breakage. This was fine for POODLE, where the attack occurs only after the handshake, when encrypted messages are sent. But not for Logjam.

As for FREAK, it is roughly the same, except that it relies on a further bug in the client implementation: the client must accept to use an ephemeral key sent by the server even though, from the point of view of the client, no such key should be sent since the client did not ask for an export RSA cipher suite (there is no non-export RSA cipher suite in SSL/TLS that still uses an ephemeral RSA key pair).

While it is tempting to state that the problem is a "protocol flaw" and lies in the fact that the export DH parameters are indistinguishable from non-export DH parameters (this is the point of view of the Logjam attack authors), my own analysis is that the true problem is the client and server both accepting to use weak crypto -- the server by willingly supporting DHE-export, the client by accepting to do some DH with a way too short modulus.

Answer 2

I believe your reasoning is solid, its just flawed

as @SOJPM pointed out:

I think SCSV prevents Protocol downgrade attacks (f. ex. TLS -> SSL) whereas FREAK and Logjam attack weak cipher suites. – SOJPM

So TLS_FALLBACK_SCSV protects the protocol used not the cipher suite.

You should disable export ciphers, SSL, RC4, etc... due to the simple fact your other ways relying upon a correct implementation on both client and server of security features like the TLS_FALLBACK_SCSV mechanism. and other mitigation. Also 1 of those machines is outside of your control you should not depend on it being correct or even right.

Disabling is also part of security in depth (only allowing a select set of ciphers apposed to a big list) and optimization of cryptography. (a limited set is easier for a server to optimize than a big set, since every cipher needs its own memory set.

Answer 3

No.
TLS_FALLBACK_SCSV won't work for this. It's just the client saying "Look, you made me come back a second time and with a downgraded protocol version!"

But Logjam or FREAK do not depend on a second connection. It works with the first connection. The downgrade is not on the protocol level. It's in the parameters that are delivered.