The FREAK bug in TLS/SSL

library
crime | hacking | security

FREAK is the latest security bug to be given an exciting name.

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), and in Apple’s SecureTransport.

(OpenSSL is the open-source implementation of TLS/SSL that gave us Heartbleed; Apple’s SecureTransport gave us goto fail.)

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…

Additionally, many servers use the same RSA key over and over again.

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).

Doing a SuperFish

There’s another spanner in the cryptographic works, too.

Cracking an RSA key is done by a technique known as “factoring the modulus,” something that is supposed to be computationally unfeasbile, except in the case of export grade keys.

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 Microsoft, Google and Mozilla.

So users of Internet Explorer, 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!)

If you are using Safari, you can also check the strength of the encryption in use after connecting to a site, but before sharing any personal data with it.

Here’s how, using Naked Security as an example.

Click on the padlock: