TLS / HTTPS · Check
Weak TLS cipher accepted — disabling CBC, RC4, and SHA-1 suites
When the server agrees to negotiate older CBC-mode, RC4, or SHA-1-based cipher suites, downgrade attacks and interoperability bugs become possible. The fix is to publish a modern cipher list — TLS 1.3 plus AEAD suites (AES-GCM, ChaCha20-Poly1305) on TLS 1.2 — and refuse anything weaker.
Why it matters
Most CDNs ship a "modern" or "restricted" cipher profile that handles this for you. If you terminate TLS at your origin, Mozilla's SSL Configuration Generator outputs a tested config for nginx, Apache, HAProxy, and others.
Real-world risk
Some clients can still negotiate older CBC or SHA1-based suites when the server offers them, widening downgrade and interoperability risk.
Fix steps (in order)
- At TLS termination, disable weak cipher suites; prefer AEAD (AES-GCM, ChaCha20-Poly1305) and TLS 1.3.
- Test with: openssl s_client -connect host:443 -cipher 'AES128-SHA' (should fail once hardened).
- Review CDN/vendor cipher suite presets and choose “modern” or “restricted” profiles.
Topic explainer
TLS versions explained: 1.0, 1.1, 1.2, 1.3 and what to disable →
What's actually different between TLS 1.0, 1.1, 1.2, and 1.3 — cipher suites, forward secrecy, performance — and which versions to disable for compliance and security.
Verify the fix in 30 seconds
Run a Scorifya scan on the affected host after deploy. The same finding id (tls_weak_cipher_probe_accepted) clears once the externally-observable signal is in place.