Skip to content
Naked Security Naked Security

The FREAK bug in TLS/SSL – what you need to know

The FREAK bug affects TLS/SSL, the security protocol that puts the S into HTTPS and the padlock in your browser's address bar. Paul Ducklin explains in plain English...

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]

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), 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…

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

Additionally, the Schannel TLS library in Microsoft Windows is vulnerable too, putting Windows software including Internet Explorer at risk.

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.


OpenSSL updated its code in January, so versions from 1.0.1k onwards don’t have this bug.

You can sidestep FREAK by upgrading OpenSSL to this or any later version.

Apple’s patch is apparently “in process,” so watch for it coming out.

Microsoft has published a list of workarounds that turn off export grade TLS encryption on Windows, which prevents FREAK attacks from working.

Image of FREAK courtesy of Shutterstock.


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.


Perhaps you are mixing up the size of AES (symmetric) keys and RSA (public-private) keys? The bits-per-key measure different things in each case. We explain here:


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.

Hope that clears it up…

For a discussion of what key length means in RSA encryption, please see:


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.


Very informative but now I’m wondering if I’ve been FREAKed.

I was getting “insecure connection” errors at and after some reading noticed all my SSL/TSL’s were on except SSL 2. Turning that on got 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 * still using it (and not more recent TSL iterations)?


Google has not supported SSL 2 for a VERRRRYYYY LONG TIME.
IF you had to enable SSL2 that means you are probably behind a Corporate Proxy server of some sort.


Well, here is what my Firefox (latest version 36.0) says about Sophos:

This website does not supply identity information.

The connection to this website is not fully secure because it contains unencrypted elements (such as images) or the encryption is not strong enough.

Then, if I click “more information”:

This website does not supply ownership information.

Technical Details
Connection Partially Encrypted
Parts of the page you are viewing where not encrypted or is not strong enough before being transmitted over the internet.

Information sent over the internet without encryption can be seen by other people while it is in transit.



What URL did you use? (I think you can get here via ‘’ as well as ‘’).

Are you browsing through a web filtering proxy or network gateway, either at work or run by your ISP?

The results I get invariably look like what you see in this article, where our “green-aura” extended validation certificate is clearly visible:


Paul, here is the link i use:
(clicked on from your email newsletter)

I am browsing from home but via a VPN service and my browser has the following addons installed; Ghostery, Better Privacy and AdBlock Plus.


I get exactly what I depicted in the abovementioned artivle – green-aura info identifying GlobalSign identifying Sophos identifying Naked Security.

Not sure what to say next :-)


Looking at this page shows as 128-bit in Chrome. I guess I must be missing something.


Missing something. You need to look at the certificate details. RSA 2048.. even then as the article states… Not a reliable method of determining FREAKage.


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

An explanation of sorts is here:


[Sigh] One more hole in all the generic cookie-cutter Android phones and tablets that will probably never be fixed.

Who said open source was more secure than proprietary code (because it could be inspected)? It’s not more secure if no one maintains it!


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.


FYI, the OSX patch came in yesterday (10 March) – also patched up Xcode in the process.


I got the OS X one in the end. A modest 4.8MByte, done in moments.

iOS 8.2, on the other hand, is a touch beefier at just over 0.5GByte :-)


Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!