Weak SSL/TLS Cipher Suites

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
Category Cryptographic Misconfiguration
Typical Severity High
OWASP A02:2021 – Cryptographic Failures
CWE CWE-326 – Inadequate Encryption Strength; CWE-327 – Use of a Broken or Risky Cryptographic Algorithm
Also known as Weak ciphers, insecure cipher suites, broken cipher negotiation, deprecated cipher support
Affected systems Web servers, load balancers, API gateways, mail servers, VPN endpoints — any service terminating TLS connections
Relevant standards RFC 8446 (TLS 1.3), RFC 7525 (BCP 195), NIST SP 800-52 Rev. 2, PCI DSS Requirement 4

Overview

A TLS cipher suite is a named combination of four cryptographic algorithms that together govern a TLS session: the key exchange mechanism, the authentication algorithm, the bulk encryption cipher, and the message authentication code (MAC). During the TLS handshake, the client presents the list of suites it supports and the server selects one. When a server is configured to accept cipher suites that rely on cryptographically broken or insufficiently strong primitives, the resulting connection is vulnerable to passive decryption, active tampering, or session hijacking — even if the certificate itself is valid.

Sensagraph automatically enumerates the cipher suites accepted by a target server and flags those considered weak or deprecated against current cryptographic standards.

How it works

During the TLS handshake (defined in RFC 8446 for TLS 1.3 and earlier RFCs for TLS 1.2 and below), the server advertises or selects a cipher suite from the client's offered list. Weaknesses arise in one or more of the four components:

  • Weak key exchange: Anonymous Diffie-Hellman (ADH/NULL), RSA key transport (no forward secrecy), export-grade 512-bit DH or RSA (exploited by FREAK and Logjam attacks), or static ECDH without ephemeral keys.
  • Broken bulk ciphers: RC4 (RFC 7465 prohibits its use — biases enable plaintext recovery), DES and 3DES (56-bit and 112-bit effective key lengths; Sweet32 birthday attack applies to 3DES in CBC mode), NULL encryption (no confidentiality at all), and EXPORT-grade ciphers (40–56 bit key lengths).
  • Weak MACs: MD5 and SHA-1 based MACs (collision vulnerabilities; BEAST attack exploits CBC mode with predictable IVs in TLS 1.0).
  • Protocol version dependency: SSL 2.0 and 3.0 are fully broken (POODLE, DROWN). TLS 1.0 and 1.1 have known weaknesses and were formally deprecated by RFC 8996 in 2021.
  • Downgrade attacks: If a server supports both strong and weak suites, an active network adversary can perform a downgrade attack (e.g., via TLS_FALLBACK_SCSV bypass) to force selection of a weaker suite.

Common examples of weak cipher suite strings include TLS_RSA_WITH_RC4_128_MD5, TLS_RSA_WITH_DES_CBC_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, and any suite containing _EXPORT_, _anon_, or _NULL_.

Business impact

Exploitation of weak cipher suites can result in:

  • Confidentiality breach: An attacker with network access (e.g., on a shared network, at an ISP level, or via BGP hijacking) can decrypt session data, exposing credentials, session tokens, PII, and business-sensitive communications.
  • Integrity loss: Weak MACs or NULL cipher configurations allow active attackers to inject or alter in-transit data without detection.
  • Regulatory and compliance penalties: PCI DSS explicitly prohibits TLS 1.0 and weak cipher suites for cardholder data environments. HIPAA, GDPR, and SOC 2 frameworks require adequate encryption. Non-compliance can result in fines, audit failures, and loss of payment processing rights.
  • Reputational damage: Public disclosure of weak encryption configurations erodes customer trust, particularly for financial services, healthcare, and e-commerce operators.
  • Forward secrecy loss: Cipher suites without ephemeral key exchange (e.g., static RSA) mean that a future compromise of the server's private key allows retrospective decryption of all previously captured traffic.

How to fix it

  1. Disable SSLv2, SSLv3, TLS 1.0, and TLS 1.1. Configure servers to support only TLS 1.2 and TLS 1.3. RFC 8996 formally deprecated TLS 1.0 and 1.1; most major browsers have removed support.
  2. Prefer TLS 1.3 cipher suites. TLS 1.3 eliminates weak primitives by design. Its three mandatory cipher suites (TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256) all use AEAD encryption with forward secrecy.
  3. For TLS 1.2, restrict to strong AEAD suites with ephemeral key exchange: Prioritize suites such as TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. Avoid CBC-mode suites where possible due to padding oracle risks.
  4. Explicitly remove weak suites from the server configuration: Disable all RC4, DES, 3DES, EXPORT, NULL, and anonymous (anon) cipher suites. Remove MD5 and SHA-1 based MACs.
  5. Enable TLS_FALLBACK_SCSV (RFC 7507) to prevent protocol downgrade attacks by clients that incorrectly retry with lower protocol versions.
  6. Use server-side cipher order preference (SSLHonorCipherOrder on in Apache; ssl_prefer_server_ciphers on in Nginx) to ensure the server's stronger suites are selected over weaker client preferences.
  7. Use strong DH parameters. If using DHE key exchange for TLS 1.2, generate a custom DH parameter group of at least 2048 bits (openssl dhparam -out dhparam.pem 2048) to mitigate Logjam.
  8. Validate with authoritative tools. After reconfiguration, test with Qualys SSL Labs Server Test (targeting an A or A+ rating) and verify the cipher list using OpenSSL: openssl s_client -connect host:443 -cipher 'RC4' should return a handshake failure.
  9. Reference Mozilla's TLS configuration generator for up-to-date recommended configurations for Apache, Nginx, HAProxy, and other common servers (linked in References).

References

Frequently asked questions

A cipher suite is considered weak if it relies on cryptographic algorithms that have known practical attacks, insufficient key lengths, or design flaws. Specific examples include RC4 (statistical biases enabling plaintext recovery), DES/3DES (insufficient key lengths and Sweet32 birthday attacks), NULL encryption (no confidentiality), EXPORT-grade ciphers (40–56 bit keys), anonymous key exchange (no authentication), and CBC-mode suites under TLS 1.0 vulnerable to BEAST-style attacks.

Not necessarily. TLS 1.2 supports a large number of cipher suites, including many broken ones. A server running TLS 1.2 can still be vulnerable if it accepts RC4, 3DES, NULL, EXPORT, or anon suites, or uses RSA key exchange without ephemeral keys (losing forward secrecy). You must explicitly restrict TLS 1.2 to strong AEAD suites with ephemeral key exchange (e.g., ECDHE).

They are related but distinct concepts. A TLS protocol version (e.g., TLS 1.0, SSL 3.0) defines the overall handshake and record-layer protocol; certain versions have fundamental, unfixable flaws (e.g., POODLE in SSL 3.0). A cipher suite specifies the cryptographic algorithms negotiated within a given protocol version. A server can run TLS 1.2 (an acceptable protocol version) while still accepting broken cipher suites. Both dimensions must be configured correctly.

Forward secrecy (or Perfect Forward Secrecy, PFS) means that the compromise of a server's long-term private key does not allow decryption of previously captured session traffic. It is achieved by using ephemeral key exchange algorithms (ECDHE or DHE) where a unique, temporary key pair is generated per session and discarded afterwards. Cipher suites based on static RSA key exchange (e.g., TLS_RSA_WITH_AES_128_CBC_SHA) lack forward secrecy, meaning a future key compromise exposes all past encrypted traffic.

Yes. PCI DSS Requirement 4 mandates the use of strong cryptography for transmission of cardholder data. PCI DSS v3.2.1 and later explicitly prohibit TLS 1.0 and require migration away from weak cipher suites. Use of RC4, DES, EXPORT ciphers, or SSLv3/TLS 1.0 in cardholder data environments constitutes a compliance violation and can result in audit failure and loss of payment processing capabilities.

You can enumerate supported cipher suites using OpenSSL: run 'openssl s_client -connect <host>:443 -cipher <suite-name>' and observe whether the handshake succeeds or fails. For comprehensive automated analysis, Qualys SSL Labs (https://www.ssllabs.com/ssltest/) provides a detailed breakdown of all supported protocols, cipher suites, and known vulnerabilities, along with an overall grade.