// FINDING / NETWORK

Weak TLS configuration

MediumNetwork

A service still accepts old protocol versions (SSL 3.0, TLS 1.0 or 1.1), weak cipher suites or key exchanges without forward secrecy, or presents a certificate that is expired, self-signed or for the wrong host name.

At a glance

Why it matters
Traffic is easier to intercept or downgrade on hostile networks, clients learn to click through certificate warnings, and the configuration fails PCI DSS and most regulator baselines. It is rarely the first step of an attack but often the finding an auditor raises first.
How to fix it
Allow TLS 1.2 and 1.3 only, with AEAD cipher suites and ECDHE key exchange. Automate certificate renewal and monitor expiry. Enable HSTS on web services. Check each public endpoint with our SSL/TLS Certificate Checker after every change.

Description

A weak TLS configuration accepts deprecated protocol versions (SSLv3, TLS 1.0, TLS 1.1), offers weak or obsolete cipher suites (RC4, 3DES, export-grade, NULL or anonymous ciphers), lacks forward secrecy, or presents a certificate that fails basic validation (expired, self-signed, or issued for a different hostname). Our SSL/TLS Certificate Checker covers the first pass: which TLS versions from 1.0 to 1.3 a server accepts, whether it accepts any of a list of known weak cipher suites, and whether the presented chain validates for the host name.

Impact

A weak configuration widens the window for a network-positioned attacker to intercept or downgrade a connection: an on-path attacker can attempt to force a downgrade to a weaker protocol or cipher the server still accepts, after which known cryptographic weaknesses in that protocol or cipher become practical to exploit for reading or manipulating traffic. Trust failures (expired or mismatched certificates) train users to click through browser warnings, which then also masks a genuine man-in-the-middle attempt behind the same familiar warning.

How we find it

  • We enumerate every protocol version and cipher suite the server accepts for the tested host and port, rather than assuming the highest offered version is the only one reachable.
  • We validate the certificate chain end to end (trust, expiry, hostname match, intermediate completeness) and check for forward secrecy in the negotiated cipher.
  • We check this consistently across every TLS-terminating endpoint in scope, since a hardened public site and a forgotten internal or legacy endpoint sharing the same certificate infrastructure are common combinations.

Fix

Disable SSLv3, TLS 1.0 and TLS 1.1 outright, restrict the cipher suite list to modern, forward-secret options, and automate certificate renewal so expiry is never a manual step someone can miss. Prefer TLS 1.3 where the platform and client base support it.

# nginx: modern TLS baseline
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';
ssl_prefer_server_ciphers off;
ssl_session_tickets off;

References

  • OWASP Transport Layer Security Cheat Sheet
  • CWE-326: Inadequate Encryption Strength
  • Mozilla SSL Configuration Generator (modern/intermediate profiles)

References