Articles

FREAK Attack: 1990s Export Crypto's Revenge

March 15, 2026 4 min read

The FREAK attack exploits a vulnerability in how web browsers and servers negotiate encryption strength, allowing attackers to downgrade connections to weak, export-grade cryptography that they can then break.

Imagine you’re trying to have a private conversation, and you agree to use a simple code with a very short key so that anyone could potentially listen in. That’s essentially what happens with FREAK. In the late 90s, US export laws restricted the strength of encryption that could be sent out of the country. To comply, software like Netscape and Internet Explorer offered "export-grade" encryption, which was intentionally weak. When these older protocols are still supported by modern systems, an attacker can trick your browser into using that weak encryption, then break it to read your traffic.

Here’s how a FREAK attack might unfold:

  1. The Setup: An attacker positions themselves between your browser and the website you’re trying to visit. This is often done using a malicious Wi-Fi hotspot or by compromising a router.
  2. The Handshake: Your browser initiates a secure connection (TLS/SSL) with the website. During this handshake, they negotiate the encryption algorithms and key lengths to use.
  3. The Downgrade: The attacker intercepts this handshake. They inject a message that tricks your browser into believing the server only supports weak, export-grade encryption (like RSA with a 512-bit key).
  4. The Weak Encryption: Your browser, designed to be compatible with older systems, agrees to use the weak encryption.
  5. The Break: The attacker now has a connection secured with very weak encryption. They can easily break this encryption and read or even modify the data exchanged between your browser and the server. This could include login credentials, personal information, or any sensitive data transmitted.

The core of the problem lies in the Diffie-Hellman (DH) cipher suites that were enabled by default in many TLS implementations. Specifically, the attack targets the ability of servers to offer and clients to accept ephemeral Diffie-Hellman (DHE) cipher suites, particularly those using small, 512-bit prime moduli.

How to Diagnose and Fix FREAK

The good news is that this is a well-understood vulnerability and has been patched in most modern software. However, if you’re running older systems or haven’t updated in a while, you might still be susceptible.

1. Check Your Server’s Cipher Suite Configuration

  • Diagnosis: Use a tool like sslyze or testssl.sh to scan your server.
    • sslyze --regular <your_domain.com>
    • testssl.sh <your_domain.com> Look for any cipher suites that include DHE (Diffie-Hellman Ephemeral) and, more importantly, check the key sizes. If you see DHE-RSA-AES128-SHA or similar with a note about weak DH primes (often 512-bit), that’s a red flag.
  • Fix: Configure your web server (Apache, Nginx, IIS) to disable weak DHE cipher suites and prioritize strong ones.
    • Nginx Example (nginx.conf or site-specific config):
      ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;
      This configuration explicitly lists strong cipher suites, prioritizing ECDHE (Elliptic Curve Diffie-Hellman, which is not vulnerable to FREAK) and strong DHE. It also disables weaker ones by exclusion.
    • Apache Example (ssl.conf or site-specific config):
      SSLCipherSuite 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1;
SSLHonorCipherOrder on;
      Similar to Nginx, this defines a strong cipher suite order. SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1; is also crucial to disable older, insecure protocols.
    • Why it works: By explicitly listing only strong cipher suites and enforcing server preference, you prevent the server from negotiating down to vulnerable, weak DHE configurations. The server dictates the strong encryption from the outset.

2. Update Your Web Server Software

  • Diagnosis: Check the version of your web server (e.g., nginx -v, apache2 -v). If you’re running versions older than those that have received FREAK patches (e.g., OpenSSL versions before 1.0.1k, GnuTLS before 3.3.16, NSS before 3.19.1), you are at risk.
  • Fix: Update your web server and its underlying TLS/SSL library (like OpenSSL).
    • Debian/Ubuntu:
      sudo apt update && sudo apt upgrade openssl nginx apache2
    • CentOS/RHEL:
      sudo yum update openssl nginx httpd
    • Why it works: Newer versions of OpenSSL and other TLS libraries have removed the problematic DHE export cipher suites or have strong checks to prevent downgrades to them.

3. Update Your Clients (Browsers, Operating Systems)

  • Diagnosis: If you manage client machines, check their browser versions and operating system patches. Older versions of Chrome, Firefox, Safari, and even operating systems might have been vulnerable.
  • Fix: Ensure all browsers and operating systems are up-to-date.
    • Browsers: Most modern browsers automatically update. For others, visit the browser’s update page.
    • Operating Systems: Run system updates. For example, on Windows: Settings -> Update & Security -> Windows Update. On macOS: System Preferences -> Software Update.
    • Why it works: Browser and OS vendors have patched their TLS implementations to ignore or reject connections attempting to use vulnerable export-grade cipher suites.

4. Disable DHE in OpenSSL (Less Common, More Drastic)

  • Diagnosis: If you’re compiling OpenSSL from source or have a very specific configuration, you might need to check OpenSSL configuration files.
  • Fix: You can disable DHE entirely or generate stronger DHE parameters.
    • Generate Stronger DHE Parameters:
      openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048
      Then, configure your web server to use these parameters (e.g., ssl_dhparam /etc/ssl/certs/dhparam.pem; in Nginx).
    • Why it works: Using larger DH parameters (2048 bits or more) makes them computationally infeasible to break in a timely manner, effectively mitigating the FREAK attack for DHE.

5. Check for Legacy Browser/Client Support

  • Diagnosis: If you are supporting very old clients or embedded systems that cannot be updated, you might need to identify and isolate them.
  • Fix: Consider disabling TLS 1.0/1.1 entirely or using specific configurations for these legacy clients if absolutely necessary, though this is generally discouraged. The ideal fix is to upgrade all clients.
  • Why it works: By disabling older TLS protocols (like TLS 1.0 and 1.1) in favor of TLS 1.2 or 1.3, you remove the handshake mechanisms that were susceptible to the FREAK downgrade.

The next error you might encounter, after fixing FREAK, is related to TLS version negotiation itself if you’ve been too aggressive in disabling older protocols and a legitimate, albeit old, client can’t connect.

Want structured learning?

Take the full Cryptography course →