The FREAK crypto downgrade attack

For the most part, cryptography is not what is letting us down security-wise. Most of the algorithms are solid and, if used correctly, essentially uncrackable in any sensible time frame. There are exceptions, of course, but by and large cryptography has served us well. Unfortunately, we commonly have programs that provide ways to downgrade the cryptographic algorithms or hamper them in other ways (e.g. shorter keys) so that they no longer serve to protect our data as they should.

When an attacker can cause systems to use a weaker encryption algorithm, perhaps one that has serious flaws, it is called a "downgrade attack". The latest entrant into the pantheon of downgrade attacks is one that has been dubbed FREAK (which stands for "Factoring attack on RSA-EXPORT keys"). It uses the ability of a man-in-the-middle attacker to downgrade the encryption used by many web sites when accessed by users with the Safari and Android browsers. As the name indicates, attackers could cause the affected systems to use the purposely weakened export version of the RSA cipher that limited key length to 512 bits.

In a delicious irony, the web site of the US National Security Administration (NSA)—which mandated the use of export-grade RSA keys during the crypto wars of the 1990s—was affected by FREAK. Many other sites were too, of course. But those sites are only vulnerable when they are accessed from a vulnerable client.

Even though the export version of the RSA suite is considered to be a "zombie" by many, it is evidently still present in multiple web servers. As Matthew Green noted in his analysis, it shouldn't matter if the web servers still have the export version of RSA available if the clients do not request the 512-bit export-grade keys. Also, clients need to reject those keys if they haven't requested them. It is the latter piece that fails here.

It turns out that a man in the middle can alter the client's initial message to the server (which is sent in the clear) to change its request for the standard RSA cipher to a request for the export version. If the server supports export RSA, it will happily send back a weak RSA key that is vouched for by the server's certificate. Apparently, roughly 35% of the internet, much of that being systems run by content delivery networks (CDNS), does or did support export-grade RSA. The client, though, knows (or should know) that it requested the standard RSA cipher so it should reject the weakened export key. But the vulnerable clients do not do that.

Even after the twin assumptions that few servers still supported export RSA and that few clients would request and accept those keys were invalidated, there was still one more line of defense: factoring 512-bit RSA keys is not trivial, so traffic could not be intercepted in realtime. It could only be read later, after the key was broken, which takes some seven hours and costs $104 on Amazon's cloud servers.

But, in reality, even that "barrier" fell. It turns out that, by default, Apache's mod_ssl will only generate a single export RSA key every time it starts up. From then on, it uses the same key over and over again. So, breaking that key once allows realtime decryption of all of the traffic from then on—until the web server gets restarted.

While man-in-the-middle attacks seemed somewhat difficult for attackers to engineer at one point in time, that is really no longer operative (if it ever really was). It is clear that governments, at least, are fully willing to perform such attacks. Any internet service provider (ISP) is perfectly positioned to attack its customers that way, as are the operators of the wireless networks in millions of locations worldwide. But, of course, encryption is meant to thwart man-in-the-middle attacks.

Part of the problem here is that TLS (or, really, its predecessor, SSL) was "designed to be broken", Green said. Because of US government mandates about exporting cryptography, SSL needed to handle both strong and weak encryption. That led to the cipher suite negotiation that would (hopefully) allow clients and servers to arrive at the strongest encryption that both could support. But it also led to attackers exploiting the ability of clients and servers to back down to simpler ciphers and protocols.

FREAK is not the first downgrade vulnerability that we have seen and it certainly won't be the last. POODLE is a famous one that exploited systems that would fall back to SSL 3, rather than require TLS 1.1 or higher, and there have been others. Even ISPs that remove STARTTLS from SMTP server responses are performing a kind of downgrade attack. When protocols are designed with the possibility to downgrade, attackers are going to try to find a way to exploit that. It is something for protocol designers to keep in mind down the road.