If I understand correctly, FREAK refers to a "vulnerability" in which, when a client offers weak cipher suites (usually export-grade cipher suites with 40 or 56 bit encryption) and a server can accept those cipher suites, a man-in-the-middle can perform a downgrade attack to use one of those weak cipher suites, and then break them (through brute-force or other weaknesses). But is this really a new attack method? I thought downgrade attacks and the possibility to use them in this manner was already known for quite a while (and this is why TLS_FALLBACK_SCSV was created). Did it just now pop into the mainstream? Did some researchers decide to give it a "brand" name and present it as a new vulnerability (since many clients/servers still offer/accept those cipher suites)? Or is there something else behind it that's not mentioned in the news? Also, I would think major, modern browsers would not be configured to offer those weak cipher suites, or at least wouldn't use them without big warnings like with invalid certificates. Did browser developers really make such an oversight?


No. TLS_FALLBACK_SCSV was designed to prevent protocol degradation (from TLSv1 to SSLv3 for example), not cipher degradations.

To mitigate against cipher degradations, the server needs to stop offer export ciphers, or the client needs to stop accepting export ciphers.

TLS_FALLBACK_SCSV is designed to fix the vulnerability of downgrades in the protocol (regardless of cipher used), because SSLv3 and prior protocols, do have vulnerabilitys that can be used regardless of cipher.

Preventing export ciphers in a client is cumbersome, because the client must support any legacy ciphers aswell for backwards compatibility. But you could check in about:config if there is possibility to disable export ciphers.

If you however is running a server, its very possible to prevent the server from offering export ciphers at all, by reconfiguring it to never offer export ciphers in the SSL configuration. Then any cipher downgrade attacks cannot happen.

Note that you still need to support TLS_FALLBACK_SCSV, since a protocol downgrade can still break a "strong" cipher due to vulnerabilitys in the implementation.

  • But still, why would browsers offer and accept weak cipher suites without any kind of warning? Considering they are doing things like deprecating certificates with SHA-1 signatures, I would expect they would do something about 40/56-bit cipher suites, since servers that only accept those suites would be pretty insecure anyway. And would a server having an EV cert but only using TLS_RSA_EXPORT_WITH_DES40_CBC_SHA still get the green URL bar? – SafeDev Mar 10 '15 at 4:40
  • 1
    No, its not the browsers deprecating the SHA-1 signatures. Its the CA's that does it for the roots. The reason for this is that Export ciphers allows you to compromise ONE site. Compromising SHA-1 however and finding a collision that would allow you to create a intermediate CA, does compromise ALL sites, yes ALL sites over the globe, even those that arent belongning to the compromised CA. Also CA's cannot Control which ciphers a SSL site offers in the negotiation. – sebastian nielsen Mar 10 '15 at 4:52
  • 1
    And EV certificates are desgined to autheticate websites. They do not, as many users Think, offer "better encryption". Even if you break TLS_RSA_EXPORT_WITH_DES40_CBC_SHA, you would still not be able to gain the private key of the site in question and impersonate as the site. All you can do is read and/or modify data in a single session. The only case where you would be able to steal the private key, is if the certificate is a old export-grade certificate without SGC, then the certificate bears 512 bit RSA keys that can be easly factored. But such certificates does not basically exist anymore. – sebastian nielsen Mar 10 '15 at 4:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.