--- key: "icdp-case-freak-logjam-2015" title: "FREAK and Logjam: export-grade key exchange" url: "https://softwaresecurity.com/domains/identity-crypto/key-management-pki/freak-logjam-export-grade-keys/" api: "https://softwaresecurity.com/api/v1/articles/icdp-case-freak-logjam-2015.json" domain: "identity-crypto" topic: "Identity \u0026 cryptography" type: "Case study" identifiers: ["CWE-757","CWE-326","A04:2025","V11.6.2","V12.1.1","V12.1.2"] tags: ["PKI and certificates","TLS","Historical cryptographic attacks"] stages: ["operate"] roles: ["developer"] license: "CC-BY-4.0" license_url: "https://creativecommons.org/licenses/by/4.0/" code_license: "MIT" --- # FREAK and Logjam: export-grade key exchange Trace two export-grade downgrade paths and separate RSA factorization from finite-field Diffie–Hellman discrete logarithms. Canonical URL: https://softwaresecurity.com/domains/identity-crypto/key-management-pki/freak-logjam-export-grade-keys/ ## In short FREAK and Logjam (2015) downgraded TLS connections to deliberately weak export-grade RSA and Diffie–Hellman keys that attackers could break. Today, offer only TLS 1.3 and TLS 1.2 with ECDHE key exchange, keep export and anonymous suites out of every build, and do not offer finite-field Diffie–Hellman in TLS 1.2, which RFC 10015 (July 2026) now forbids; TLS 1.3 uses only named groups of 2048 bits or more. Judge a connection by the key exchange it actually used, not by the certificate’s key size. - FREAK forced a 512-bit temporary RSA key; Logjam forced 512-bit export Diffie–Hellman. - A strong certificate key does not protect a weak key exchange it signs. - Precomputation against widely shared primes made attacks on common DH groups cheaper. - Moving a weak suite to the bottom of the preference list leaves it negotiable by an active attacker. - Mozilla’s current intermediate TLS profile uses only ECDHE key exchange, with no finite-field DHE suites. ## Incident at a glance - Date: 2015-03-03 to 2015-05-20 - Category: Protocol attack - Organizations: OpenSSL Project; Apple; Microsoft - CVE: [CVE-2015-0204](https://nvd.nist.gov/vuln/detail/cve-2015-0204), [CVE-2015-1067](https://nvd.nist.gov/vuln/detail/cve-2015-1067), [CVE-2015-1637](https://nvd.nist.gov/vuln/detail/cve-2015-1637), [CVE-2015-4000](https://nvd.nist.gov/vuln/detail/cve-2015-4000) - Impact: A man-in-the-middle could downgrade TLS connections to 512-bit export-grade RSA (FREAK) or Diffie–Hellman (Logjam) keys and break them. When Logjam was disclosed, 8.4% of the top million HTTPS domains were vulnerable. - How it was found: FREAK came from systematic state-machine testing of TLS libraries by INRIA-led researchers; Logjam came from a multi-institution study of Diffie–Hellman deployment. ### Timeline 1. 2014-10-22: Karthikeyan Bhargavan of INRIA reports the export-RSA client flaw to OpenSSL. 2. 2015-01-08: OpenSSL fixes CVE-2015-0204 in 1.0.1k, 1.0.0p and 0.9.8zd and rates it low severity. 3. 2015-03-03: FREAK is disclosed. 4. 2015-03-10: Microsoft bulletin MS15-031 fixes the Schannel flaw (CVE-2015-1637). 5. 2015-03-19: OpenSSL reclassifies CVE-2015-0204 as high severity. 6. 2015-05-20: Logjam is disclosed (CVE-2015-4000). 7. 2015-06-11: OpenSSL 1.0.2b and 1.0.1n make clients reject Diffie–Hellman parameters shorter than 768 bits. 8. 2015-10-13: The Logjam paper is published at ACM CCS 2015. 9. 2016-08: RFC 7919 defines negotiated finite-field Diffie–Hellman groups for TLS. 10. 2026-07: RFC 10015 forbids RSA key exchange and finite-field DHE cipher suites in TLS 1.2. ## Verify it 1. Run `testssl.sh --freak --logjam host:443` against every endpoint and confirm both report not vulnerable. 2. Offer only export or DHE suites from a TLS 1.2 test client and confirm the handshake fails. 3. Record the key-exchange group from a fresh handshake, for example with the inventory commands in the TLS guide at /domains/identity-crypto/key-management-pki/tls-pki-operations/. 4. Search custom TLS configuration for `EXPORT`, `EXP`, `aNULL` and hand-generated DH parameter files. ## What you will learn - Explain FREAK and Logjam as distinct downgrade mechanisms. - Calculate a small DH shared secret. - Review actual key-exchange parameters rather than certificate labels. Audience: Engineers who configure TLS servers and clients, and reviewers who check what key exchange a handshake really uses. Before you start: - Distinguish RSA key transport, finite-field Diffie-Hellman and authenticated negotiation. Time: About 17 minutes: 4 to read and 13 for the exercise ## Negotiated labels and signed parameters diverged FREAK and Logjam were disclosed in 2015 against the long tail of export-era TLS support. Export restrictions had encouraged deliberately small cryptographic parameters. Years later, compatibility paths still allowed attackers to steer some handshakes toward those weaker constructions. FREAK combined server support for export RSA with client implementation behavior that accepted an export-style temporary RSA key in a context where it should not. The attacker could induce a small temporary RSA modulus, factor it, and use the recovered key against handshakes that reused that temporary key. A strong certificate key did not rescue a weak temporary key used for the actual key transport. Logjam targeted finite-field Diffie–Hellman. In affected handshakes, the server’s signature authenticated DH parameters but did not bind the cipher-suite choice in the way needed to prevent the export downgrade. The attacker could make the server select `DHE_EXPORT` while presenting the exchange as ordinary DHE to the client. A client that accepted the small group then used a problem small enough for the attack. ## The arithmetic and amortization are different RSA factorization recovers factors of a modulus. DH discrete logarithms recover an exponent from a public value such as g^a mod p. These are distinct mathematical problems. Both can yield session secrets when used with deliberately weak parameters, but the attacks’ preparation, reuse, and runtime conditions differ. Logjam’s researchers emphasized precomputation tied to a shared finite-field prime. Expensive group-specific work can be amortized over many servers using that same group, after which individual logarithms are cheaper. This is not equivalent to recovering every DH private key merely because a prime is public; public group parameters are normal. The concern is insufficient strength and the economics of shared weak groups. The original attacks involved negotiation and parameter-validation weaknesses, not a claim that an authenticated handshake can be modified arbitrarily. The Finished messages authenticate the transcript, but an attacker who obtains the weak exchange’s secret can compute the needed authenticators. Protection that arrives after the exploitable exchange is insufficient. ## Remove export paths and validate the actual parameters Disable export suites at servers, update affected clients, and reject unacceptable key-exchange parameters. Merely moving export suites to the bottom of the preference list leaves them available to an active downgrade. Checking only the certificate’s RSA bit length misses the temporary RSA key or DH group that actually determined the session secret. Current TLS deployments should follow maintained protocol profiles, with TLS 1.3 preferred and approved TLS 1.2 configurations where needed. For any compatibility exception, record the actual group or temporary key, not a generic label such as strong TLS. Parameter validation belongs at the consumer of the signed parameters as well as in a configuration dashboard. Changing a weak DH prime to a unique but equally small prime may disrupt a particular precomputation advantage while leaving the fundamental parameter-strength problem. Similarly, frequently regenerating a tiny temporary RSA key changes attack economics but does not make export-grade key transport an acceptable design. ## What should you do today? - Offer TLS 1.3, plus TLS 1.2 with ECDHE suites only; TLS 1.3 negotiates only named groups and has no export suites. - Do not offer finite-field DHE in TLS 1.2: RFC 10015 (July 2026) forbids it. In TLS 1.3 the finite-field groups are the RFC 7919 named groups of 2048 bits or more, never a custom or 1024-bit prime. - Make clients reject weak parameters: no export suites, no DH groups below 2048 bits, no RSA keys below 2048 bits. The weak RSA key guide at /domains/identity-crypto/key-management-pki/weak-rsa-key-generation/ covers key sizes and generation. - Check with `testssl.sh --freak --logjam host:443`, and record the negotiated group from a fresh handshake. ## Keep toy DH separate from the historical exploit The exercise shows how small DH values yield a shared secret once an exponent is found. It does not reproduce transcript rewriting, RSA factorization costs, or real Logjam precomputation. Historical claims should be tied to the papers’ tested clients and servers, rather than every TLS product from that period. Deployment evidence should include a normal supported exchange, rejection of export-only negotiation, and rejection of unacceptable offered parameters even when their signature is valid. A valid certificate proves who signed parameters; it does not prove the parameters meet the application’s security policy. ## Guided practice A toy DH exchange demonstrates why public parameter size matters. ### Supplied material ```text p=23, g=5. Client public A=8; server public B=19. Supplied powers: 5^1 mod 23=5; ^2=2; ^3=10; ^4=4; ^5=20; ^6=8. Server exponent is b=15 (provided for checking only). A separate service has a 2048-bit certificate key but a 512-bit temporary export RSA key. ``` ### 1. Recover the toy exponent Find a from the table and calculate B^a mod 23 by repeated squaring. Worked answer: a=6. 19² mod 23=16; 19⁴ mod 23=3; 19⁶ mod 23=3×16 mod 23=2. The shared secret is 2. ### 2. Distinguish key roles Decide whether the 2048-bit certificate protects the small temporary RSA key from factorization. Worked answer: No. The certificate authenticates the temporary key, but confidentiality depends on the temporary key’s strength. ### 3. Classify repairs Evaluate disabling export only by preference and choosing a unique but small DH prime. Worked answer: Preference leaves a negotiable path. A unique small prime may remove shared precomputation reuse but does not meet a sound group-strength policy. Remove export and validate actual parameters. Deliverable: A DH calculation and a table separating certificate identity, exchange parameters, and final policy acceptance. Scope: Tiny DH values are intentionally insecure arithmetic. No live downgrade or historical exploit is executed. Articles and teaching material: CC BY 4.0. Original executable code: MIT. Attribution: Software Security. ## Sources - [Bhargavan et al.: A Messy State of the Union (IEEE S&P 2015)](https://antoine.delignat-lavaud.fr/doc/oakland15.pdf) - [Logjam researchers: Weak Diffie-Hellman and the Logjam Attack](https://weakdh.org/) - [OpenSSL: Logjam, FREAK and upcoming changes (May 20, 2015)](https://openssl-library.org/post/2015-05-20-logjam-freak-upcoming-changes/) - [RFC 7919: Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS](https://www.rfc-editor.org/rfc/rfc7919.html). August 2016. - [Mozilla Server Side TLS configuration generator (guidelines 6.0)](https://ssl-config.mozilla.org/) - [RFC 10015: Deprecating obsolete key exchange methods in TLS 1.2 and DTLS 1.2](https://www.rfc-editor.org/rfc/rfc10015.html). July 2026. - [Matthew Green: Attack of the week, FREAK](https://blog.cryptographyengineering.com/2015/03/03/attack-of-week-freak-or-factoring-nsa/). 3 March 2015. - [Microsoft Security Bulletin MS15-031: Schannel FREAK fix (CVE-2015-1637)](https://learn.microsoft.com/en-us/security-updates/securitybulletins/2015/ms15-031). 10 March 2015. - [OpenSSL Security Advisory: CVE-2015-0204 reclassified as high severity](https://openssl-library.org/news/secadv/20150319.txt). 19 March 2015. - [OpenSSL Security Advisory: Logjam protection (CVE-2015-4000)](https://openssl-library.org/news/secadv/20150611.txt). 11 June 2015.