FREAK Attack on Export-Grade RSA
FREAK Attack on Export-Grade RSA
Description
This vulnerability indicates that the server is susceptible to FREAK attacks, which exploit support for weak export-grade RSA encryption to downgrade TLS connections and break encryption through cryptographic factoring.
FREAK (Factoring RSA Export Keys) occurs when servers accept RSA_EXPORT cipher suites with 512-bit keys, a legacy of 1990s US export restrictions. Vulnerable clients incorrectly accept these weak keys even when not requested, allowing attackers to force downgrade attacks and factor the weak encryption.
How It Works:
- Man-in-the-middle attacker intercepts TLS handshake between client and server
- Client requests strong encryption, but attacker forwards request asking for RSA_EXPORT
- Server responds with weak 512-bit RSA key instead of standard 2048-bit key
- Vulnerable client accepts the weak key due to implementation bugs
- Attacker factors the 512-bit RSA key (takes hours/days) and decrypts all traffic
Requirements:
- Server must support RSA_EXPORT cipher suites (legacy export-grade encryption)
- Client must have vulnerable TLS implementation accepting weak keys
- Man-in-the-middle network position to intercept and modify handshakes
- Computational resources to factor 512-bit RSA keys
Example Scenario: A mobile app connects to a banking API over public WiFi. An attacker intercepts the TLS handshake and tricks the server into offering a 512-bit export-grade RSA key. The vulnerable client (using old OpenSSL) accepts this weak key. The attacker spends 8 hours factoring the key using cloud computing resources, then decrypts all subsequent API traffic to steal authentication tokens and financial data.
The vulnerability exploits historical US export restrictions that limited cryptographic strength, affecting legacy systems that still support these intentionally weakened cipher suites for backward compatibility.
Recommendation
To mitigate FREAK attacks:
Primary Defense - Disable Export Cipher Suites:
# Apache - disable export-grade ciphers
SSLCipherSuite HIGH:!aNULL:!MD5:!EXP:!RC4
# More secure configuration
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:!EXP
# Nginx - disable export ciphers
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:!EXPORT:!DES:!RC4:!MD5:!PSK:!SRP:!CAMELLIA;
Update TLS Libraries:
Ensure all TLS implementations are patched: - OpenSSL 1.0.1k+ (CVE-2015-0204 fixed) - Update mobile apps using vulnerable libraries - Patch embedded systems and IoT devices
Testing for FREAK Vulnerability:
# Test server for export cipher support
openssl s_client -connect example.com:443 -cipher EXPORT
# Should fail with "no cipher match" if properly configured
# Test with SSL Labs
curl "https://api.ssllabs.com/api/v3/analyze?host=example.com"
Client-Side Protection:
# Python - disable export ciphers
import ssl
context = ssl.create_default_context()
context.set_ciphers('ECDHE+AESGCM:ECDHE+CHACHA20:DHE+AESGCM:DHE+CHACHA20:!aNULL:!MD5:!DSS:!EXPORT')
Additional Mitigations:
- Use TLS 1.3 which completely removes export cipher support
- Implement perfect forward secrecy (PFS) with ECDHE/DHE key exchange
- Regularly audit cipher suite configurations for weak algorithms
- Monitor for unusual TLS negotiation patterns indicating downgrade attempts
Modern browsers and servers have disabled export ciphers by default, but legacy systems and embedded devices may still be vulnerable.
Links
Standards
- SOC2_CONTROLS:
- CC_6_7
- CC_7_1
- CCPA:
- CCPA_1798_150
- GDPR:
- ART_32
- PCI_STANDARDS:
- REQ_4_1
- REQ_6_2
- REQ_11_3