Cipher Strength

The cipher suite negotiated during a TLS handshake determines the actual cryptography protecting the connection. Even with TLS 1.2 or 1.3 negotiated, an old or misconfigured server can still pick a weak cipher (RC4 stream cipher, 3DES, NULL encryption) that gives an attacker a real path in. Cipher Strength checks the negotiated cipher name against a deny-list of broken tokens.

How the check works

RedScore performs a TLS handshake against each primary HTTPS host and reads the cipher suite name (e.g. TLS_AES_256_GCM_SHA384, ECDHE-RSA-AES128-GCM-SHA256). The name is uppercased and matched against a deny-list. If any of the following tokens appear in the cipher name, the host scores zero:

• RC4: broken stream cipher (BEAST, biases in keystream).
• DES: 56-bit, brute-forceable in hours.
• 3DES: 168-bit nominal but only ~80-bit effective; Sweet32 birthday attack.
• MD5: collision-broken since 2008.
• NULL: no encryption at all.
• EXPORT: 1990s deliberately-weakened 40-bit ciphers.
• ANON: anonymous Diffie-Hellman; no server authentication.
• IDEA: deprecated; weak by modern standards.

Empty cipher (no TLS handshake) also scores zero. Anything else, including all modern TLS 1.2 ECDHE-AES-GCM and TLS 1.3 AES-GCM/ChaCha20 suites, scores 5/5.

How the verdict maps to evidence

• Pass (5/5 per host): cipher suite name does not contain any of the banned tokens.
• Fail (0/5 per host): banned token in cipher name, or no TLS handshake.

Like TLS Protocol Version, this reflects the cipher the server NEGOTIATED with the scanner, not every cipher it accepts. A server that supports both modern and weak ciphers may pass this check (modern preferred during negotiation) while still accepting weak ciphers from old clients. Disable weak ciphers explicitly; do not rely on negotiation order.

Fix: configure modern cipher suites only

The fastest path is to use the Mozilla SSL Configuration Generator at ssl-config.mozilla.org and pick the Intermediate profile. It generates a tested cipher list for nginx, Apache, HAProxy, AWS ELB, Caddy, and others. The Intermediate profile bans every cipher RedScore checks for and supports clients back to about 2014.

Mozilla Intermediate profile (manual)

ssl_protocols TLSv1.2 TLSv1.3;
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:DHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

SSLProtocol             -all +TLSv1.2 +TLSv1.3
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:DHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder     off
SSLSessionTickets       off

TLS 1.3 cipher suites are negotiated separately and have a fixed, all-modern set: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256. Server config does not need to list them; just enabling TLS 1.3 enables all three.

Managed CDNs and platforms

• Cloudflare: cipher suites are managed automatically. Default settings ban all weak ciphers; no action needed.
• AWS CloudFront: pick TLSv1.2_2021 or TLSv1.3 security policy on the distribution. Both ban weak ciphers.
• AWS ALB / NLB: pick ELBSecurityPolicy-TLS13-1-2-2021-06 or ELBSecurityPolicy-TLS13-1-3-2021-06.
• Fastly: managed TLS configurations follow Mozilla profiles by default.
• Vercel, Netlify, Cloudflare Pages, Render, Heroku, App Engine: managed TLS, no weak ciphers.

Verify the fix

• echo | openssl s_client -connect yourdomain.tld:443 -servername yourdomain.tld 2>/dev/null | grep -E 'Cipher|Protocol' shows what was negotiated.
• Test that weak ciphers are refused: openssl s_client -connect yourdomain.tld:443 -servername yourdomain.tld -cipher 'RC4-SHA' < /dev/null. Should fail with "no cipher match" or similar handshake error.
• ssllabs.com/ssltest reports the full cipher list the server accepts, plus the order the server prefers. Look for any red rows under "Cipher Suites".
• testssl.sh (open source CLI) gives the same coverage as ssllabs and runs locally: testssl.sh https://yourdomain.tld
• Re-run the RedScore lookup. Pass requires the negotiated cipher to avoid every banned token on every primary HTTPS host.

Common pitfalls

• Negotiated cipher modern, accepted ciphers leaky. The check measures negotiation, not the full accepted list. Old clients that ask for RC4 or 3DES may still get them. Disable weak ciphers in the cipher_list, do not just rely on preference order.
• ssl_prefer_server_ciphers on without a clean list. The server's cipher preference order only matters if the list itself is clean. With on, the server picks; with off (recommended for TLS 1.3 era), the client picks. Either way, the list must not contain weak ciphers.
• Old OpenSSL on the server. OpenSSL 1.0.2 is end-of-life and lacks modern cipher support. Upgrade to 1.1.1 minimum, ideally 3.x.
• Conflicting CDN-and-origin policies. CDN serves modern, origin accepts weak. The CDN protects external traffic, but origin should also refuse weak ciphers in case anyone reaches it directly. Fix at both layers.
• DHE without proper dhparam size. DHE cipher suites need a strong dhparam (Diffie-Hellman parameters) of at least 2048 bits. Older Apache and nginx defaults use 1024-bit dhparam, which is weak even with otherwise-good cipher names. Generate fresh dhparam: openssl dhparam -out dhparam.pem 2048
• Compliance variation. PCI DSS, FIPS 140, FedRAMP, and others have their own cipher requirements. The Mozilla Modern profile (TLS 1.3 only) is overkill for most; Intermediate (TLS 1.2+ with the modern AEAD ciphers) hits all common requirements.