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.