Rule Information
Tags
gosecuritycryptorc4stream-cipherrfc7465wepfms-attackCWE-327OWASP-A02
CWE References
Interactive Playground
Experiment with the vulnerable code and security rule below. Edit the code to see how the rule detects different vulnerability patterns.
pathfinder scan --ruleset golang/GO-CRYPTO-004 --project .1
2
3
4
5
6
7
8
9
rule.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Cross-file analysis: 3 files
About This Rule
Understanding the vulnerability and how it is detected
RC4 is a stream cipher designed in 1987. It was widely used in SSL/TLS, WEP (802.11 Wi-Fi), and WPA-TKIP. It has been comprehensively broken and is prohibited in all new uses by RFC 7465 (February 2015).
**Fluhrer-Mantin-Shamir (FMS) attack (2001)**: RC4's key scheduling algorithm (KSA) produces statistical biases in early keystream bytes when certain "weak IVs" are used. In WEP, IVs were transmitted in the clear and incorporated directly into the per-packet RC4 key. Tools like aircrack-ng automated FMS to recover 128-bit WEP keys from ~100,000 captured packets, completely breaking WEP in practice within months of the FMS publication.
**AlFardan et al. (2013)**: Statistical analysis demonstrated that RC4's keystream biases allow plaintext recovery in TLS with enough ciphertext samples. The most likely plaintext byte value at certain positions can be recovered from ~2^24 TLS sessions — demonstrated against HTTP session cookies in real HTTPS traffic.
**RFC 7465 (February 2015)**: Explicitly prohibits RC4 cipher suites in TLS: - TLS clients MUST NOT include RC4 cipher suites in ClientHello. - TLS servers MUST NOT select RC4 when a client offers it. - If a client offers ONLY RC4, the server MUST terminate the handshake.
RC4 is available in Go's standard library as `crypto/rc4`, which the package documentation explicitly labels as "cryptographically broken and should not be used for secure applications." Any use of rc4.NewCipher for security purposes must be replaced with AES-GCM.
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
WEP/Wi-Fi Session Decryption
RC4 with predictable IV construction (as used in WEP) leaks keystream bytes. aircrack-ng recovers the 128-bit WEP key in minutes using 100,000 captured packets via the FMS attack. Any RC4 implementation with low-entropy or predictable IVs is similarly vulnerable.
2
TLS Session Cookie Theft
AlFardan et al. (2013) demonstrated recovery of HTTP session cookies from TLS sessions using RC4 by exploiting byte-position biases in RC4's keystream. After 2^24 TLS connections, individual plaintext bytes at predictable positions can be recovered with statistically significant probability.
3
Keystream Reuse
If the same RC4 key is used to encrypt two messages (keystream reuse), XORing the two ciphertexts gives the XOR of the plaintexts. Given known plaintext patterns (HTTP headers, protocol markers), full message recovery is possible.
How to Fix
Recommended remediation steps
- 1Replace all rc4.NewCipher usage with AES-GCM (crypto/aes + crypto/cipher.NewGCM).
- 2For environments without hardware AES, consider ChaCha20-Poly1305 (golang.org/x/crypto/chacha20poly1305) — used in TLS 1.3 and WireGuard.
- 3Never use RC4 in any new protocol, application, or configuration.
- 4For TLS: Go's crypto/tls defaults are safe — do not override to add RC4 cipher suites.
- 5Remove any RC4 cipher suites from existing TLS server configurations.
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
Detects imports and calls to the crypto/rc4 standard library package (NewCipher). The package documentation labels RC4 as "cryptographically broken." Any direct use of rc4.NewCipher warrants immediate replacement with AES-GCM or ChaCha20-Poly1305.
Compliance & Standards
Industry frameworks and regulations that require detection of this vulnerability
RFC 7465 (February 2015)
RC4 cipher suites are prohibited in TLS. MUST NOT offer or select RC4.
URL: https://datatracker.ietf.org/doc/html/rfc7465
NIST SP 800-131A Rev 2 (2019)
RC4 is not an approved algorithm. AES is the approved replacement.
PCI DSS v4.0
Requirement 4.2.1 — Strong cryptography required. RC4 is not strong cryptography.
OWASP Top 10
A02:2021 — Cryptographic Failures
References
External resources and documentation
RFC 7465 — Prohibiting RC4 Cipher Suites (IETF, February 2015)On the Security of RC4 in TLS and WPA — AlFardan et al. (USENIX Security 2013)Fluhrer, Mantin and Shamir (FMS) WEP attack — WikipediaFMS attack paper applied to WEP (Stubblefield et al. 2001)Go crypto/rc4 package — standard library (labeled cryptographically broken)Go golang.org/x/crypto/chacha20poly1305 packageGo crypto/cipher package — AES-GCMCWE-327: Use of a Broken or Risky Cryptographic Algorithm
Similar Rules
Explore related security rules for Go
HIGH
Use of MD5 Weak Hash Algorithm
Detects use of MD5 (crypto/md5) which is cryptographically broken — collision attacks are feasible in seconds and GPU cracking reaches 164 billion hashes/second.
HIGH
Use of SHA1 Weak Hash Algorithm
Detects use of SHA1 (crypto/sha1) which has a proven collision (SHAttered, 2017) and is deprecated by NIST for all applications through 2030.
HIGH
Use of DES or 3DES Weak Cipher
Detects use of DES/3DES (crypto/des) — DES uses a 56-bit key exhausted in 22 hours (1999); 3DES is vulnerable to the SWEET32 birthday attack and disallowed by NIST after December 31, 2023.
Frequently Asked Questions
Common questions about Use of RC4 Stream Cipher
RC4 is a stream cipher designed in 1987. It was widely used in SSL/TLS, WEP (802.11
Wi-Fi), and WPA-TKIP. It has been comprehensively broken and is prohibited in all new
uses by RFC 7465 (February 2015).
**Fluhrer-Mantin-Shamir (FMS) attack (2001)**: RC4's key scheduling algorithm (KSA)
produces statistical biases in early keystream bytes when certain "weak IVs" are used.
In WEP, IVs were transmitted in the clear and incorporated directly into the per-packet
RC4 key. Tools like aircrack-ng automated FMS to recover 128-bit WEP keys from ~100,000
captured packets, completely breaking WEP in practice within months of the FMS publication.
**AlFardan et al. (2013)**: Statistical analysis demonstrated that RC4's keystream biases
allow plaintext recovery in TLS with enough ciphertext samples. The most likely plaintext
byte value at certain positions can be recovered from ~2^24 TLS sessions — demonstrated
against HTTP session cookies in real HTTPS traffic.
**RFC 7465 (February 2015)**: Explicitly prohibits RC4 cipher suites in TLS:
- TLS clients MUST NOT include RC4 cipher suites in ClientHello.
- TLS servers MUST NOT select RC4 when a client offers it.
- If a client offers ONLY RC4, the server MUST terminate the handshake.
RC4 is available in Go's standard library as `crypto/rc4`, which the package documentation
explicitly labels as "cryptographically broken and should not be used for secure applications."
Any use of rc4.NewCipher for security purposes must be replaced with AES-GCM.
Use Code Pathfinder to scan your codebase: pathfinder scan --ruleset golang/GO-CRYPTO-004 --project .
This vulnerability is rated as HIGH severity.
Yes! Code Pathfinder allows you to customize rules. Modify detection patterns, adjust severity levels, add custom sanitizers, and configure the rule to fit your organization's security policies.
New feature
Get these findings posted directly on your GitHub pull requests
The Use of RC4 Stream Cipher rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.