Update. this article originally listed Microsoft Windows and Internet Explorer as safe against FREAK. But Microsoft has now confirmed that the vulnerability exists in its Schannel TLS library too. The article has been amended accordingly. [2015-03-05T20:25Z]

It was found by an impressive team of researchers, including some Microsofties, so it’s solid research work.

The bug affects TLS/SSL, the security protocol that puts the S into HTTPS and is responsible for the padlock in your browser’s address bar.

The bug is known to exist in OpenSSL’s TLS implementation (before version 1.0.1k), in Apple’s SecureTransport, and in the Schannel TLS library that is part of Microsoft Windows.

Man in The Middle

Greatly simplified, FREAK is an attack that can be done by a “man in the middle” (someone who can listen into and change the network traffic between you and your destination server).

Using FREAK, he can trick you and the server into settling on a much weaker HTTPS encryption scheme than either of you would normally accept.

Basically, he gets you to use what’s called “export grade” RSA encryption, a hangover from the 1990s when the US required exported encryption to be deliberately weakened.

The idea was that export grade keys were just about good enough for everyday, not-so-secret use, but could be cracked by superpowers with supercomputers if national security should demand it.

→ “Export grade” encryption probably sounds like a silly idea. That’s because it was a silly idea. People simply bought proper encryption code from outside the US, which hurt the US software industry; meanwhile, any Americans who ended up using export grade connections without realising put themselves at a security disadvantage. The idea was largely abandoned by 2000.

Legacy danger

No-one should be using export grade keys any more – indeed, no-one usually does – but many clients and servers still support them.

Somehow, it never seemed to matter that the code was still lying around, as long as everyone avoided it.

Longstoryshort is that a TLS session using export grade RSA encryption can be sniffed, saved, and then fairly easily cracked later on.

Forget 1990s state-of-the-art, where cracking an export grade session was tractable, but only just. (A team of researchers cracked an export grade key without using supercomputers in 1999, thus proving it was already worryingly insecure, but it took them seven months.)

Today, we are talking about two weeks of cracking on a decent $2000 laptop, or 12 hours and $100 using Amazon’s cloud.

In other words, export grade keys are not OK, even for everyday, not-so-secret use, not at all.

An injury to one…

In theory, this is not a bad thing, because RSA keys aren’t supposed to be crackable, so you can save processing power by not creating a new key every time.

But in the context of FREAK, it may mean that, after cracking a server’s export grade key, you can use the result to decrypt other sessions, using the same key, without paying another $100 (and without waiting another 12 hours).

Loosely speaking, that means you decompose the key into its public part (which is supposed to be public) and its private part (which you are never, ever supposed to get your hands on).

With the private key, you can now sign traffic from your own imposter website as though it came from a trusted third party.

Indeed, the team behind the original FREAK research claim to have done just that to create a fake nsa dot gov.

Being able to sign your own traffic with someone else’s private key means that you can “do a SuperFish,” and masquerade as someone else without producing any tell-tale certificate warnings in your victim’s browser.

What to do?

This trick only works if you end up with a TLS connection secured with an export grade RSA key.

As far as we know, the trick doesn’t work against the TLS implementations used by Google and Mozilla.

So users of Chromium/Chrome and Firefox are OK.

Browsers that use OpenSSL are at risk, which includes Android’s now-disowned “Browser” browser, and therefore probably Samsung’s derived browser known as “Internet.”

Likewise, Apple’s own implementation of TLS, called Secure Transport, puts OS X software that uses it at risk, including Safari.

In the short term, if you are worried, try using an alternative browser. (But make sure you know how to configure it to your usual privacy standards, and how to keep it updated!)

Update. This part of the article [until 2015-03-05T19:50Z] used to contain a sequence of steps to check the RSA key size of a TLS connection in Safari. We suggested that if you saw a key size of 512, you could assume you had been FREAKed. Alert reader mrhack1982 tells us that we were wrong. FREAK trickily drops the RSA key used to set up encryption to 512 bits, so the encryption can be cracked. But Safari’s [Show Certificate] dialog still shows the RSA keysize used for the TLS certificate, typically 2048 bits. It’s like signing a genuine signature but handing over a fake credit card.

After reading I got a bit concerned that Facebook’s key is only 256 bit. But then found an article on CloudFlare that explained to this layperson that a smaller number doesn’t *always* mean less secure. (Elliptic Curves, etc.) Might be helpful for some that don’t fully grasp some of the complexity and nuance of public key encryption.

Looking at the screenshot, does this mean your website is vulnerable since its using RSA encryption? WHat you are trying to say about the 2048 bits is that your website is ok for now but in time it will change to 500 something when somebody attacks it? please clarify this for us

Good question! I should have explained the 512-versus-2048-bits issue in the article.

Current standards say that 2048-bit RSA keys can be considered safe against cracking. So most websites today with RSA keys use 2048-bit keys (or longer), as you see here with Naked Security’s 2048-bit key.

But “export grade” RSA keys are deliberately limited to 512 bits, which cannnot be considered safe against cracking.

So, if you make an HTTPS connection and Safari tells you that the RSA key is 512 bits, you are unsafe – and, because no-one deliberately uses 512-bit keys any more, the most likely explanation would be that your connection had been FREAKed in order to trick both you and the server into accepting that 512-bit key.

See the updated article. The keysize you see when you [Show certificate] is *not* the size of the RSA key that FREAK changes. So you see the keysize for the TLS certificate, which is not necessarily the same as the keysize used to set up encryption. Sorry about that.

I was getting “insecure connection” errors at docs.google.com and after some reading noticed all my SSL/TSL’s were on except SSL 2. Turning that on got docs.google.com to load but in reading your article sounds like that’s the hack – – to get me to downgrade to SSL 2 thereby opening myself up to FREAK attacks. (I shouldn’t be enabling SSL 2 right?)

And if SSL 3 is now known to be bad, why is *.google.com still using it (and not more recent TSL iterations)?

The 128-bit part refers to the AES encryption used for scrambling the actual traffic. Public key encryption (even RSA 512-bit) is far too slow for real-time traffic scrambling. So the RSA part is actually used to agree on a random *symmetric* key, which then encrypts all subsequent data.

The bit sizes of AES keys and RSA keys measure different things, so an RSA-512 key is weak, but an AES 128-bit key is strong. (In a similar vein, the 8km horizontal trip into town is nothing compared to the 8km vertical ascent of Everest 🙂

What’s ironic, is that once you turn on the SSL cipher enforcement per Microsoft’s KB, you can’t reach their KB 3046015 page anymore. Their using TLS 1.0 with RSA (one of the ciphers they left out). Also other major sites like ADP (payroll for a lot of companies) don’t work either after enforcing MS’s settings. Dead in the water unless you use a safe browser.