The FREAK Attack
On Tuesday, March 3, 2015, researchers announced a new SSL/TLS vulnerability called the FREAK attack. It allows an attacker to intercept HTTPS connections between vulnerable clients and servers and force them to use weakened encryption, which the attacker can break to steal or manipulate sensitive data. This site is dedicated to tracking the impact of the attack and helping users test whether they’re vulnerable.
The FREAK attack was discovered by Karthikeyan Bhargavan at INRIA in Paris and the miTLS team. Further disclosure was coordinated by Matthew Green. For additional details, see this post by Matt Green, this site by the discoverers, this Washington Post article, and this post by Ed Felten.
Who is vulnerable?
The FREAK attack is possible when a vulnerable browser connects to a susceptible web server—a server that accepts “export-grade” encryption.
Servers that accept RSA_EXPORT cipher suites put their users at risk from the FREAK attack. Using Internet-wide scanning, we have been performing daily tests of all HTTPS servers at public IP addresses to determine whether they allow this weakened encryption. More than a third of all servers with browser-trusted certificates are at risk.
Currently VulnerableChange Since Mar. 3HTTPS servers at Alexa Top 1 Million domain names8.5%down from 9.6%HTTPS servers with browser-trusted certificates6.5%down from 36.7%All HTTPS servers11.8%down from 26.3%
|Currently Vulnerable||Change Since Mar. 3|
|HTTPS servers at Alexa Top 1 Million domain names||8.5%||down from 9.6%|
|HTTPS servers with browser-trusted certificates||6.5%||down from 36.7%|
|All HTTPS servers||11.8%||down from 26.3%|
Update (Mar. 5): Browsers are vulnerable to the FREAK attack because of bugs that allow an attacker to force them to use weak, export-grade encryption. One example is the OpenSSL bug described in CVE-2015-0204, but some other TLS libraries have similar problems. Far more browsers are vulnerable to the FREAK attack than was initially thought when the attack was announced, including:
|Internet Explorer||Patch available now — Security advisory|
|Chrome on Mac OS||Patch available now|
|Chrome on Android||Patch available now|
|Safari on Mac OS||Patch available now|
|Safari on iOS||iOS 8 Patch available now|
|Stock Android Browser||Patch available now|
|Opera on Mac OS||Patch available now|
Chrome for Windows and all modern versions of Firefox are known to be safe. However, even if your browser is safe, certain third-party software, including some anti-virus products and adware programs, can expose you to the attack by intercepting TLS connections from the browser. If you are using a safe browser but our client test says you’re vulnerable, this is a likely cause. You can check whether your browser is vulnerable using the Qualys SSL Client Test.
In addition to browsers, many mobile apps, embedded systems, and other software products also use TLS. These are also potentially vulnerable if they rely on unpatched libraries or offer RSA_EXPORT cipher suites.
What should I do?
If you run a server …
You should immediately disable support for TLS export cipher suites. While you’re at it, you should also disable other cipher suites that are known to be insecure and enable forward secrecy. For instructions on how to secure popular HTTPS server software, we recommend Mozilla’s security configuration guide and their SSL configuration generator. We also recommend testing your configuration with the Qualys SSL Labs SSL Server Test tool.
If you use a browser …
Make sure you have the most recent version of your browser installed, and check for updates frequently. Updates that fix the FREAK attack should be available for all major browsers soon.
If you’re a sysadmin or developer …
Make sure any TLS libraries you use are up to date. Unpatched OpenSSL, Microsoft Schannel, and Apple SecureTransport all suffer from the vulnerability. Note that these libraries are used internally by many other programs, such as wget and curl. You also need to ensure that your software does not offer export cipher suites, even as a last resort, since they can be exploited even if the TLS library is patched.