SuperFREAK! SuperFREAK! Temptations, sing!

Remember those heady days back when people spelled out W-W-W and H-T-T-P in all their links, and we had to contend with "export only" versions of cryptography because if you let those 1024-bit crypto keys fall into the wrong hands, the terrorists would win? My favourite remnant of those days is this incredibly snide Apple ad where tanks surround the new Power Mac G4, the first personal computer classified by the Pentagon as a munition ("As for Pentium PCs, well ... they're harmless").

Unfortunately, a less amusing remnant of that bygone era has also surfaced in the form of the FREAK attack (see also POODLE, CRIME and BEAST). The idea with export-grade ciphers is that, at the time, those naughty foreign governments would have to make do with encrypting their network traffic using short keylengths that the heroic, not-at-all-dystopian denizens of the NSA could trivially break (which you can translate to mean they're basically broken by design). As a result, virtually no browser today will advertise its support for export-grade ciphers because we're not supposed to be using them anymore after the Feds realized the obvious policy flaw in this approach.

But that doesn't mean they can't use them. And to prove it, the researchers behind FREAK came up with a fuzzing tool that gets in the middle of the secure connection negotiation (which must happen in the clear, in order to negotiate the secure link) and forces the connection to downgrade. Ordinarily you'd realize that something was in the middle because completing the handshaking to get the shared secret between server and client requires a private key, which the malicious intruder doesn't have. But now it has another option: the defective client will accept the downgraded connection with only a 512-bit export-compliant RSA key from the server, trivial to break down with sufficient hardware in this day and age, which the intruder in the middle can also see. The intruder can factor the RSA modulus to recover the decryption key, uses that to decrypt the pre-master secret the client sends back, and, now in possession of the shared secret, can snoop on the connection all it wants (or decrypt stored data it already has). Worse, if the intruder has encrypted data from before and the server never regenerated the RSA key, they can decrypt the previous data as well!

There are two faults here: the server for allowing such a request to downgrade the connection, and the client for accepting deficient keys. One would think that most current servers would not allow this to occur, stopping the attack in practice, and one would be wrong. On the FREAK Attack site (which doubles as a test page), it looks like over a quarter of sites across the IPv4 address space are vulnerable ... including nsa.gov!

What about the client side? Well, that's even worse: currently every Android phone (except if you use Firefox for Android, which I recently switched to because I got tired of Android Chrome crashing all the damn time), every iOS device, and every Mac running Safari or Chrome is vulnerable, along with anything else that ships with a vulnerable version of OpenSSL. Guess what's not? Firefox. Guess what's also not? TenFourFox. NSS does not advertise nor accept export-only keys or ciphers. TenFourFox is not vulnerable to FREAK, nor any current version of Firefox on any platform. Test it yourself.

Classilla is vulnerable in its current configuration. If you go into the settings for security, however, you can disable export-only support and I suggest you do that immediately if you're using Classilla on secure sites. I already intended to disable this for 9.3.4 and now it is guaranteed I will do so.

What about Safari or OmniWeb on Power Macs? I would be interested to hear from 10.5 users, but the test site doesn't work correctly in either browser on 10.4. Unfortunately, because all Macs (including 10.6 through 10.10) are known to be vulnerable, I must assume that both Tiger and Leopard are also vulnerable because they ship a known-defective version of OpenSSL. Installing Leopard WebKit fixes many issues and security problems but does not fix this problem, because it deals with site display and not secure connections: the browser still relies on NSURL and other components which use the compromised SSL library. I would strongly recommend against using a non-Mozilla browser on 10.7 and earlier for secure sites in the future for this reason. If you use Android as I do, it's a great time to move to Firefox for Android. Choice isn't just a "nice thing to have" sometimes.