This is the story of how a handful of cryptographers ‘hacked’ the NSA. It’s also a story of encryption backdoors, and why they never quite work out the way you want them to.
But I think I’m getting ahead of myself a bit here.
A group of cryptographers at INRIA, Microsoft Research and IMDEA have discovered some serious vulnerabilities in OpenSSL (e.g., Android) clients and Apple TLS/SSL clients (e.g., Safari) that allow a ‘man in the middle attacker’ to downgrade connections from ‘strong’ RSA to ‘export-grade’ RSA. These attacks are real and exploitable against a shocking number of websites — including government websites. Patch soon and be careful.
You can find a detailed description of the work by the researchers — Beurdouche, Bhargavan, Delignat-Lavaud, Fournet, Kohlweiss, Pironti, Strub, Zinzindohoue, Zanella-Béguelin — at their site SmackTLS.com. You should go visit that site and read about the exploits directly. The proof of concept implementation also involved contributions from Nadia Heninger at U. Penn.
I’m going to explain the rest of it in the ‘fun’ question and answer format I save for this kind of attack.
What is SSL/TLS and what are ‘EXPORT cipher suites’ anyway?
Or rather, that’s the theory. In practice, SSL and TLS have been a more like a work in progress. In part this is because they were developed during an era when modern cryptographic best practices weren’t nailed down yet. But more to the point: it’s because even when the crypto is right, many software implementations still get things wrong.
With all that in mind, there’s a third aspect of SSL/TLS that doesn’t get nearly as much attention. That is: the SSL protocol itself was deliberately designed to be broken.
Let me explain what I mean by that.
Back in the early 1990s when SSL was first invented at Netscape Corporation, the United States maintained a rigorous regime of export controls for encryption systems. In order to distribute crypto outside of the U.S., companies were required to deliberately ‘weaken’ the strength of encryption keys. For RSA encryption, this implied a maximum allowed key length of 512 bits.*
The 512-bit export grade encryption was a compromise between dumb and dumber. In theory it was designed to ensure that the NSA would have the ability to ‘access’ communications, while allegedly providing crypto that was still ‘good enough’ for commercial use. Or if you prefer modern terms, think of it as the original “golden master key“.
The need to support export-grade ciphers led to some technical challenges. Since U.S. servers needed to support both strong and weak crypto, the SSL designers used a ‘cipher suite’ negotiation mechanism to identify the best cipher both parties could support. In theory this would allow ‘strong’ clients to negotiate ‘strong’ ciphersuites with servers that supported them, while still providing compatibility to the broken foreign clients.
This story has a happy ending, after a fashion. The U.S eventually lifted the most onerous of its export policies. Unfortunately, the EXPORT ciphersuites didn’t go away. Today they live on like zombies — just waiting to eat our flesh.
If EXPORT ciphers are known to be broken, what’s the news here?
We don’t usually worry about export-grade cipher suites very much, because supposedly they aren’t very relevant to the modern Internet. There are three general reasons we don’t think they matter anymore:
- Most ‘modern’ clients (e.g., web browsers) won’t offer export grade ciphersuites as part of the negotiation process. In theory this means that even if the server supports export-grade crypto, your session will use strong crypto.
- Almost no servers, it was believed, even offer export-grade ciphersuites anymore.
- Even if you do accidentally negotiate an export-grade RSA ciphersuite, a meaningful attack still requires the attacker to factor a 512-bit RSA key (or break a 40-bit symmetric cipher). This is doable, but it’s generally considered too onerous if you have to do it for every single connection.
What these researchers did was develop a fairly beautiful piece of formal analysis tooling that allows them to ‘fuzz’ the state machines of most modern SSL/TLS implementations. They found a bunch of wonderful things in the course of doing this — some of them quite nasty. I’m not going to cover all of them in this post, but the one we care about here is quite simple.
You see, it turns out that some modern TLS clients — including Apple’s SecureTransport and OpenSSL — have a bug in them. This bug causes them to accept RSA export-grade keys even when the client didn’t ask for export-grade RSA. The impact of this bug can be quite nasty: it admits a ‘man in the middle’ attack whereby an active attacker can force down the quality of a connection, provided that the client is vulnerable and the server supports export RSA.
- In the client’s Hello message, it asks for a standard ‘RSA’ ciphersuite.
- The MITM attacker changes this message to ask for ‘export RSA’.
- The server responds with a 512-bit export RSA key, signed with its long-term key.
- The client accepts this weak key due to the OpenSSL/SecureTransport bug.
- The attacker factors the RSA modulus to recover the corresponding RSA decryption key.
- When the client encrypts the ‘pre-master secret’ to the server, the attacker can now decrypt it to recover the TLS ‘master secret’.
- From here on out, the attacker sees plaintext and can inject anything it wants.
How common are export-enabled TLS servers?
No matter how bad you think the Internet is, it can always surprise you. The surprise in this case is that export-grade RSA is by no means as extinct as we thought it was.
(Facebook have updated their configuration as a result of this work.)
Factoring an RSA key seems pretty expensive for breaking one session.
This brings us to the most awful part of this attack. You don’t have to be that fast.
PoC or GTFO.
Fortunately, a proof of concept for this attack requires only a few ingredients. First, you need some tooling to actually run the MITM attack. Then you need the ability to (quickly) factor 512-bit RSA keys. From there it’s just a question of finding a vulnerable client and server.
![]() |
This is what happens to EC2 spot pricing when Nadia runs 75 ‘large’ instances to factor a 512-bit key. |
Just because someone says an implementation is vulnerable doesn’t mean it actually is. You should ask for proof.
To factor the 512-bit export keys, the project enlisted the help of Nadia Heninger at U. Penn, who has been working on “Factoring as a Service” for exactly this purpose. Her platform uses cado-nfs on a cluster of EC2 virtual servers, and (with Nadia doing quite a bit of handholding to deal with crashes) was able to factor a bunch of 512-bit keys — each in about 7.5 hours for $104 in EC2 time.
Since the NSA was the organization that demanded export-grade crypto, it’s only fitting that they should be the first site affected by this vulnerability. There’s great video on the SmackTLS site. After a few hours of factoring, one can take the original site (which looked like this):
And change it into this:
![]() |
Attack images courtesy Karthik, Antoine INRIA. |
Some will point out that an MITM attack on the NSA is not really an ‘MITM attack on the NSA’ because NSA outsources its web presence to the Akamai CDN (see obligatory XKCD at right). These people may be right, but they also lack poetry in their souls.
Is it patched?
The most recent of OpenSSL does have a patch. This was announced (though not very loudly) in January of this year.
Apple is working on a patch.
Akamai and other CDNs are also rolling out a patch to solve these problems. Over the next two weeks we will hopefully see export ciphersuites extinguished from the Internet. In the mean time, try to be safe.
What does it all mean?
You might think this is all a bit absurd and doesn’t affect you very much. In a strictly technical sense you’re probably right. The client bugs will soon be patched (update your devices! unless you have Android in which case you’re screwed). With good luck, servers supporting export-grade RSA cipher suites will soon be rare curiosity.
Still, to take this as the main lesson of the work would, I think, be missing the forest for the trees. There’s a much more important moral to this story.
The export-grade RSA ciphers are the remains of a 1980s-vintage effort to weaken cryptography so that intelligence agencies would be able to monitor foreign traffic. This was done badly. So badly, that while the policies were ultimately scrapped, they’re still hurting us today.
This might be an academic point if it was only a history lesson. However, for the past several months, U.S. and European politicians have been publicly mooting the notion of a new set of cryptographic backdoors in systems we use today. While the proposals aren’t explicit, they would presumably involve deliberately weakening encryption tech so that governments can intercept and read our conversations. While officials carefully avoid the term “back door” — or any suggestion of weakening our encryption systems against real attackers — this is wishful thinking. These systems are already so complex that even normal issues stress them to the breaking point. There’s just no room for new backdoors.
To be blunt about it, the moral is pretty simple:
Encryption backdoors will always turn around and bite you in the ass. They are never worth it.
Acknowledgements
Special thanks to Karthik and Antoine for sharing this with me, Nadia for factoring, Ivan Ristic for interrupting his vacation to get us data, and the CADO-NFS team for the software that made this possible.
Notes:
This comment has been removed by the author.
This comment has been removed by the author.
Not to be all super-sensitive, but that ?Walking Dead? (I think?) screencap is really, really disturbing if you're not someone who watches the show. If you don't know it's a show, it's basically 4chan gore material. It took me a minute to notice the people in the background and then make out the character whose sexy costume analogues were everywhere last Halloween.
Anyway. Just wanted to mention that perspective.
This comment has been removed by the author.
“Lack poetry” — great!
I agree with this sentiment, halloween/gore material does not befit the subject very well – it serious and well written article and might as well have pics to back that up with
What is sad is that OpenSSL disabled the EXPORT1024 ciphersuites in 2006. If you don't know what these are, in year 1999 the US government raised the limit to 56-bit encryption and 1024-bit RSA. They were described in https://tools.ietf.org/html/draft-ietf-tls-56-bit-ciphersuites . And for the record it was in year 2000 that the restrictions was removed for “retail” software.
To go over some of the technical details, attacker can't just generate a 512-bit RSA key as the key in the ServerKeyExchange message is signed by the server, and the Finished message don't prevent the attack as all the hash depends on is the master secret that can be obtained after the 512-bit RSA key is factored. As a side note, this make me wonder if a similar attack is possible with 512-bit DHE. A server still using it is https://www.ssllabs.com/ssltest/analyze.html?d=mobilelinkgen.com
Yes, that is *incredibly* sensitive. There's no gore at all in that screen capture, even if you zoom in on it. There's far worse on the news every night, even pre-watershed.
(Unless it has been changed since your comment, in which case, sorry)
Yes, that is *incredibly* sensitive. There's no gore at all in that screen capture, even if you zoom in on it. There's far worse on the news every night, even pre-watershed.
(Unless it has been changed since your comment, in which case, sorry)
Nice work on the crypto breaking.
Thanks for making us safer.
Nice work on the crypto breaking.
Thanks for making us safer.
To the people complaining about zombies – grow a backbone. Stop getting so offended over everything little thing on the internet.
OpenSSL is the descendent of SSLeay (eay = Eric A Young) who with a few others wrote the library – the Crypto, ASN.1, bignum, etc. in Australia outside of the export controls, so everyone could use it. Those in the USA could import it.
So the only servers that used weak crypto were the ones in the USA.
I'm not finding the details on this, leading me to speculate that the MITM is choosing an EXPORT40 in it's server-hello selection that wasn't originally offered in the the client-hello, and that the client is accepting that EXPORT40. (is this the bug?). If so, then I'm also under the impression that this would only be vulnerable to SSLv2, not SSLv3+, as I believe handshake is protected in the MAC, i.e. protected in SSLv3+. The attack on an SSLv3+ would fail MAC check by both real client and server. If this is the attack, than it's scope is really quite limited, to a combined client&server that allow SSLv2. Further FREAK then sounds like a long well known attack, with a new easy to remember name that's catchy among various media outlets.
Hey Steve (security now)you were right(trust no one)
As forssl and TLS taking a longtime to secure?Steve point out there is no reason for the delay .even HE is almost ready to release his secure ID suite called S.Q.R.L ,as some know before mostly in assembler.nha most likely some don't want web 100% secure and have to ask a jjudge to peer at Obama bedroom webcam
Except the factoring allow the MITM to obtain the master secret and recompute the finished hash.
@anonymous: regarding details on the exact vulns and how to craft a MITM, see .
ALL: in regards to Matthew's “what does it all mean?” section, see also: “Surveillance or Security?”, Susan Landau, MIT Press, 2011 –
rats, the link to the paper was elided by blogger. so anyway, it's linked-to from the http://www.smacktls.com page as the “technical paper” (smack.pdf)
I can vouch for the export control silliness. In 93/94 I implemented PEM while in England and in about 3 weeks was able to exchange PEM encrypted email with the TISPEM reference implementation. At the time the UK government was also using the same export control policy and we decided it was not possible to export the PEM product.
From what I understood, this attack is only feasible against Apache mod_ssl -based applications or websites, because Apache mod_ssl by default generates a single export-grade RSA key when the server starts up (or against any other Apple SecureTransport or OpenSSL -based application that has the same behavior), so you can factor the RSA modulus to recover the corresponding RSA decryption key offline and reuse it in future sessions (during the lifetime of this key). Otherwise, it seems unfeasible that a handshake would last for 7.5 hours, right?
Good work guys (Y). I hope google will come up with a fix soon for android devices.
Below is an infographic based on FREAK sites by country.
https://infogr.am/https_sites_that_support_rsa_export_suites
Cool 🙂 Yet another race to patch this just begun, it departments are probably 'excited' 🙂 Although it's better to have a bug fixed rather than lurking somewhere.
Export grade ciphers suck.
https://www.fortify.net/sslcheck.htm
From what I can see in ssl_engine_kernel.c on line 1313, current version of Apache uses the same algorithm for generating DH and EXPORT keys. I can assume EXPORT keys don't usually live long and unique for every client, just as DH. So you're right.
“they also lack poetry in their souls.”
Beautiful…
The EXPORT keys (do you mean RSA_EXPORT keys — used to encrypt — or DH(E)_RSA_EXPORT where RSA is used to sign (*)) might be generated using the same function than DH values. However, it doesn't imply that the generation is done every SSL/TLS session.
(*) RSA_EXPORT: RSA used for encryption, size <= 512 bits
DH(E)_RSA_EXPORT: RSA used for signature, size >= 512 bits
Handbag clutching people who take themselves too seriously really grind my gears.
Great article. Thanks.
Here's a useful SSL FREAK Checker: https://tools.keycdn.com/freak
Let's you know if your site is vulnerable.
Temporary RSA 512 Bit Keylife for FREAK attack
So I’ve patched OpenSSL’s s_client a bit to print temporary RSA 512 public key used for EXPORT cipher
Then grabbed domain list from freakattack.com, got first IP addresses from domain with
and ran
parallel -u -a ips.txt -j20 './run.sh {}'
twice to collect temporary RSA 512 bit keys, where run.sh is as follows:then count all domains with more than 4 unique RSA key lines:
Total hosts in list: 415
Hosts with enabled EXPORT: 368
Hosts with random keys for every connection: 137
Hosts with static keys for every connection: 231
freak-rsa-keylife.md
hosted with ❤ by GitHub
I share your concern about the government's request to allow all Internet communication to be able to be read by them, so please don't take this comment as me being an apologist for backdoors in cryptology. However, there are alternative ways to allowing the internet traffic to be read without weakening the cryptology. For example, the communications could be signed with the government's public key at the same time it is signed by your own public key. The cryptology would remain strong until the government's private key is accidentally leaked.
May you elaborate on the comment that Android users are “screwed?” Would it be because a patch to Android's OpenSSL would have to go through the customary path Google-Manufacturer-Cell carrier-User?
Alan Turing would be proud. 😉
you could use a sniffer to record the traffic and go back and decyrypt it once you've factored the key, couldn't you? then you wouldn't worry how long the key was actively used…
which would NEVER happen, right?
Terrific article … thanks for sharing!
Really like the WD pic.
I'm not sure if you can do downgrade attack without the key. I suppose key negotiation is signed with this exact key, but I'm not sure.
Where on earth is it possible to get the OpenSSL patches or the changed source code lines for each OpenSSL files?
Has anyone made a determination yet as to whether or not this affects the client-side of the Java TLS/SSL stack?
thank you – JBM needs to quit life
sage
Matthew, isn't it time to do an OpenSSL audit, like the one which is in progress for TrueCrypt?
This vulnerability was the result of an audit by a team that wrote special tools to do it. So what you want is already happening, and them publishing their results is what is triggering you to ask for someone to do something like they just did.
The authors state ” In other words, the JSSE implementation of TLS has been providing virtually no security guarantee (no authentication, no integrity, no confidentiality) for the past several years. ” in the 8th paragraph of their web site: https://www.smacktls.com/.
So yes, it affects the client-side of the Java TLS/SSL stack.
Why is the current stable Chrome 40.0.2214.109 for Android vulnerable while Chrome Beta for Android is not? Both support the exact same cipher suites. Many thanks!
Don't forget how the “key escrow” backdoor in Lotus Notes used 768-bit RSA, and remember that the key has to be factored only once!
Probably a reference to the fact that over half of devices in use are not supported anymore and are running years-old OS versions.
A horror story, not far from it, because my question is simply, how much else we do not know or somebody does not want us to know.
Is there anyone who is aware of entire technology and possibilities of attacks?
I am asking because we created all these protocols, and if we left these gaps here that we know of now, then nothing will ever be secure, since obviously there is a general humongous problem in the entire industry: the software industry is NOT trust worthy even at the lowest possible level.
If this attack has been exploited for 35 years (35 years!) and nobody said a word about it, then there is a dominant extreme culture of silencing among technical staff everywhere in this world and this is very very very very very bad news. I am not surprised that we have only one person talking at the moment openly.
A horror story to the highest possible degree.
yep.
Matthew, thanks for the explanation of this.
While I agree that it's important to be aware of these things and get them fixed ASAP, and I agree that enryption backdoors in general are a really bad idea, I disagree with your conclusion in this particular case that this is all because of an “encryption backdoor”. Because from what I can see, this is mostly down to a client implementation flaw which allows the client to do something it is not supposed to do (allowing the cipher to be downgraded when they never offered it in the first place), combined with a server implementation flaw which it should not be allowed to do. (The long-term key usage thing)
Yes, if servers offer lower-grade encryption then that makes this scenario more likely to occur. But the reason servers sometimes offer that lower-grade encryption is because some clients (still a bunch out there!) have a choice between that, or no encryption at all. And it's not particularly ironic that these sometimes happen to be government-run websites – those same websites are mandated to be usable by the widest possible spectrum of citizens and UA's possible, even if they are vision-impaired, and/or using an old computer with a small screen and an old OS that does not support modern encryption protocols, can't render pages with complex AJAX scripting and so on. Unlike profit-driven websites, the government has a mandate to serve *everyone*.
So, it's a tradeoff. There are still a lot of people with analog TV sets and 40-year-old radios which can still tune in radio stations. I think the real guilty parties in this particular case are the people who released that buggy client and server code.
I think the author is trying to draw a parallel between the fiction and hype portrayed in the movie and his own article.
The January 2015 critical update for Java 1.5, 1.6, 1.7 and 1.8 prevents the attack.
https://technet.microsoft.com/en-us/library/security/ms15-031.aspx
Even microsoft's schannel seems broken..
Awesome idea and you have represent it awesomely. I am really impressed with the quality of article.. Have a nice day ahead and tc – http://mp3freesongs.net
Does nginx also createand re-use a single RSA key when it starts? I am confused on the relationship between export cipher suites with max 512-bit RSA keys and modern server certificates that are 2048-bits or greater.
Something is really not clear for me. Please let me explain my doubts: I know that once the certificate arrived to the client, and after that the client check that it's ok, it take the public key contained into this certificate (that is usually at 2048 bits, but however not less then 1024) and encrypt the pre-master key for the symmetrick cryttography. How can this attack reduce this key to 512 bits if it is 2048 bits? Other question, in the article is written that the RSA key are the same until the server go down, but how is possible since the key is written in the certificate? If it change the signature of the certification authority is not valid…please, someone help me to understand ;(
Thank you very much for expression and sharing.