FREAK vulnerability exploits old encryption export restrictions

To understand the latest security problem facing the web today, we have to use the DeLorean and return to the 1990s. It was a different time. Gasoline was cheaper, we were all trying to figure out exactly what Kurt Cobain was singing, and the NSA controlled the export of encryption from the U.S.

As one might expect, the NSA controlling encryption exports was a contentious issue. The agency had no particular interest in helping anyone outside of the U.S. actually secure their communications. It created a split world in which American citizens had access to better encryption ciphers, such as SSL with 1024-bit asymmetric encryption and 128-bit symmetric encryption. The rest of the world, meanwhile, was only eligible for encryption approved for export, which limited SSL to 512-bit asymmetric and 40- or 56-bit symmetric encryption. This weak export encryption solution gave the NSA the ability to continue monitoring international communications. More than just SSL suffered from this NSA decision, as well. The ancient VPN protocol, PPTP, supports three strengths of encryption to accommodate export: 40-, 56-, and 128-bit. Export restrictions even created controversy around Microsoft operating systems.

What makes the situation silly is that the NSA's efforts weren't all that effective. It was possible to bypass the IP checks and obtain the stronger encryption reserved for the United States. Security organizations like RSA took advantage of foreign branches because importing strong encryption was easier than exporting it. You could implement foreign libraries to re-implement stronger encryption in RSA's software. The 128-bit version wasn't even the front-and-center option for folks in the U.S., resulting in a large swath of the populace running the weak international version. Bill Clinton finally brought about sanity to this mess with his executive order 13026 (PDF).

A recurring theme in security and computing is that nothing stays secret forever. Secret instructions in a processor will not remain a secret. Neither will secret backdoors in software. The choice to create a separate, weaker set of encryption tools for the world had implications for legitimate global commerce then, and it's come back to bite us with a FREAK vulnerability disclosed yesterday.

OpenSSL and Apple's Secure Transport interface both have a bug. They will accept inferior, export-grade keys even when the client doesn't ask for them. This situation opens up a perfect man-in-the-middle (MitM) situation. The attacker can take advantage of a MitM proxy and force the client to downgrade to an export-level cipher while asking the victim's desired resource to also provide export encryption. The server replies with a weak 512-bit RSA public key, which can then be factored to uncover the matching private key. When the client finally passes the secret key for the symmetric half of SSL/TLS, the attacker is able to decrypt the public key encryption protecting the secret key. At this point, the world is a place of plain-text bliss, as this harmless video demonstration shows.

Several questions may stem from this, such as how are the bad guys managing to factor this public key so quickly? Through the cloud, of course. Nadia Heninger has created "Factoring as a Service" that takes advantage of the CPU horsepower on tap through a cloud-based virtualization service to factor 512-bit keys in just seven and a half hours. The cost? $104.

If you're thinking that timeframe still seems too slow, keep in mind that servers only have one export key pair for all the SSL/TLS transactions they handle. In other words, the bad guys only have to put in the time, money, and effort once to impact everyone who uses a given service. Why so few keys on a server? The easy answer is CPU time. The more complex answer is CPU time and a sufficient entropy pool.

Some of you may be seeing this as an issue for servers, as well. If servers didn't offer the option, then flawed clients wouldn't be in quite so perilous a situation. Unfortunately, at press time, 36.7% of the 14 million secured sites on the web still offer an export-grade cipher. In a bit of hilarity, nsa.gov is one of those sites. I'm happy to report that TR does not offer weaker encryption.

Apple iOS and OS X are impacted. Apple is expected to release a patch for both platforms next week. If you use Chrome on OS X, make sure you update to version 41.0.2272.76. Firefox on Macs is also safe.

Android is impacted, though Firefox on Android is safe. Google is likely to fix its own software through Google Play Services, and Nexus devices should get an OS update to address the problem. Other device makers may only push out OS updates for newer products, though. Much like the Heartbleed situation with Android 4.1.1, some systems will likely remain broken.

There are sporadic reports of Blackberry 10.3.1.2267 devices being affected, plus some sort of weird regression in the Windows 10 Beta. (No supported production Microsoft OS or browser is impacted.) These may not be accurate.