FREAK

FREAK
Name	FREAK
Type	Security vulnerability / cryptographic downgrade attack
Affected	SSL 3.0, TLS 1.0, TLS 1.1, OpenSSL, NSS, Secure Transport
Disclosed	2015
Cvss	4.3 (example)
Aliases	RSA_EXPORT, "Factoring Attack on RSA-EXPORT Keys"

FREAK

FREAK was a cryptographic downgrade vulnerability discovered in 2015 that allowed active network attackers to force servers and clients to use weak, export-grade RSA keys. The issue originated from legacy United States export restrictions on cryptography and involved interoperability between cipher-suite negotiation implementations in widely used libraries and products. Researchers disclosed the weakness after coordinated analysis of implementations in libraries such as OpenSSL, NSS, and Apple's Secure Transport, and vendors including Microsoft, Google, and Apple issued guidance and patches.

Overview

FREAK traces its roots to 1990s United States Department of Commerce export controls and the Bureau of Industry and Security policies that produced "export-grade" cipher suites limited to 512-bit RSA keys. The vulnerability surfaced when researchers examined interactions among client software (browsers like Google Chrome, Apple Safari, Mozilla Firefox, Microsoft Internet Explorer), server software (web servers running Apache HTTP Server, nginx, Microsoft IIS), and cryptographic libraries (notably OpenSSL, NSS, LibreSSL). Attackers performing active man-in-the-middle operations could downgrade TLS/SSL handshakes by inducing selection of export-grade RSA key exchange, then exploit the small key size using factoring algorithms and services that could recover the private key, enabling decryption, content tampering, or session hijacking.

Technical Details

FREAK exploited the TLS/SSL handshake mechanism and the interaction between client hello and server key exchange messages. In typical RSA key exchange, a client sends a ClientHello listing supported cipher suites; the server selects a cipher and replies with ServerHello and a certificate chain. With export-grade RSA, servers would generate ephemeral 512-bit RSA keys and sign them with the server certificate. The flaw arose in implementations that accepted the server's usage of an export RSA key even when the client had not explicitly advertised export-grade cipher suites. Attackers could strip or modify the client hello and server responses during a TLS handshake, causing clients and servers to negotiate export-grade RSA. Once the server used a 512-bit RSA key, attackers used integer factoring algorithms—such as variants of the General Number Field Sieve—or outsourced factoring to services leveraging clusters or cloud providers like Amazon Web Services to factor the modulus and derive the private exponent.

Security Implications and Exploitation

Successful exploitation permitted passive and active network attackers—positioned on public Wi‑Fi, compromised routers, or state-level interceptors—to decrypt sessions or perform man-in-the-middle operations against connections to major sites including those run by Google, Yahoo!, and ecommerce platforms. The attack specifically targeted TLS endpoints on ports commonly used for HTTPS and related protocols, undermining authentication guarantees provided by certificates issued by authorities such as DigiCert, Comodo, and Let's Encrypt (then emerging). Besides web browsing, other protocols built on TLS stacks—like SMTP with STARTTLS, IMAP over TLS, and custom APIs—were at risk if clients or servers accepted export RSA cipher suites. Researchers demonstrated practical end-to-end exploits using automated tools, and proof-of-concept code circulated among incident responders and vendors.

Mitigation and Patches

Vendors responded by removing support for export-grade cipher suites and fixing negotiation logic in libraries. OpenSSL and LibreSSL released updates disabling RSA export cipher suites by default; Mozilla updated NSS and browser policies; Google pushed changes in Chromium and Android; Apple patched Secure Transport in iOS and macOS updates; Microsoft issued advisories and updates for Windows. Recommended mitigations included disabling export cipher suites, disabling RSA key exchange in favor of ephemeral Diffie–Hellman variants (for example ECDHE) with strong curves like secp256r1, enforcing TLS 1.2+, and ensuring servers do not generate temporary weak RSA keys. Network defenders used intrusion detection rules in systems such as Snort and Suricata to detect downgrade attempts and monitored certificate transparency logs produced by Google Certificate Transparency for suspicious ephemeral certificates.

Impact and Incidents

The disclosure affected hundreds of millions of devices and servers and triggered emergency patch cycles across major vendors. Major browsers and server operators reported varying percentages of endpoints vulnerable prior to patches; news reports and technical advisories named corporations including Apple, Google, Microsoft, and Yahoo! in the disclosure timeline. While there were no widely publicized large-scale breaches directly attributed to FREAK, security teams observed targeted exploitation in certain networks, and security researchers used the event to highlight risks of legacy export policy remnants in modern stacks. The incident influenced procurement and compliance discussions within organizations such as National Institute of Standards and Technology and became a case study in vulnerability management and coordinated disclosure practices involving entities like CERT/CC.

Related Protocols and History

FREAK is part of a lineage of protocol-level downgrade and cryptographic weaknesses born from legacy policy decisions and interoperability choices, related to earlier and later issues such as Logjam, RSA-EXPORT historical policies, and vulnerabilities in SSL 3.0 like the POODLE attack. The broader history includes policy events such as the 1996 Communications Assistance for Law Enforcement Act debates and subsequent export control relaxations in the late 1990s and early 2000s. Cryptographic communities, including contributors from IETF working groups and standards bodies such as IEEE, have since emphasized stronger negotiation, forward secrecy via Diffie–Hellman and Elliptic Curve Diffie–Hellman, and protocol hardening to avoid similar downgrade vectors.

Category:Computer security exploits