TLS misconfiguration

What it is#

Transport Layer Security authenticates endpoints and protects network traffic from observation and modification. A TLS misconfiguration exists when the deployed protocol, certificate, algorithms, or surrounding HTTP behavior provides less protection than the application requires.

Common findings include TLS 1.0 or 1.1 support, weak cipher suites, expired or mismatched certificates, incomplete certificate chains, insecure renegotiation, inconsistent HTTPS redirects, mixed content, and internal services that silently fall back to plaintext.

TLS is an end-to-end system. A secure public load balancer does not compensate for an unprotected connection from that load balancer to an application carrying the same sensitive data.

Why it matters#

• Interception or modification of credentials, session cookies, API data, and personal information.
• Server impersonation when certificate validation is disabled or hostname checks fail.
• Downgrade to obsolete protocol behavior and weaker cryptography.
• Exposure of internal service traffic to adjacent hosts or compromised network devices.
• Compliance failures where supported protocols and algorithms do not meet policy.
• Loss of availability when certificates expire or chains are deployed incorrectly.

Examples#

# Vulnerable: obsolete protocol versions remain enabled.
server {
    listen 443 ssl;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL;
}

# Fixed: support TLS 1.2 and TLS 1.3 only.
server {
    listen 443 ssl;
    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;
}

Cipher configuration depends on the TLS library, client population, and policy. Generate it from a maintained baseline and test it against the actual deployed endpoint.

How to fix it#

1. Disable obsolete protocols. Permit TLS 1.2 and TLS 1.3 unless a documented, time-limited compatibility exception requires otherwise. TLS 1.0 and 1.1 are deprecated.

2. Use an approved cipher baseline. Prefer authenticated encryption with forward secrecy. Remove export, anonymous, null, RC4, DES, 3DES, and other policy-prohibited suites.

3. Automate certificate lifecycle. Use a trusted certificate authority, correct subject names, complete chains, protected private keys, monitored expiration, and tested renewal.

4. Validate certificates everywhere. Clients must verify trust chain, hostname, validity period, intended use, and revocation behavior where required. Never disable verification to resolve development certificate errors.

5. Enforce HTTPS. Redirect HTTP only for user convenience; do not process credentials or sensitive actions before the redirect. Deploy HSTS after every required hostname is HTTPS-ready.

6. Protect internal hops. Use TLS or mutually authenticated TLS between proxies, services, databases, queues, and administrative systems according to the threat model.

7. Remove mixed content. Load scripts, styles, images, fonts, WebSockets, and APIs over secure schemes. Use CSP reporting to locate regressions.

8. Protect keys. Restrict filesystem and service access, use managed key services or hardware protection where appropriate, rotate after suspected exposure, and prevent keys from entering images or source control.

9. Test changes before rollout. Maintain a documented client-compatibility policy and controlled exception process with owners and expiration dates.

How to test for it#

• Enumerate every public and internal TLS endpoint, including alternate ports, APIs, mail, databases, load balancers, and service meshes.
• Test supported protocol versions and cipher suites using approved scanners from authorized networks.
• Verify certificate names, chain, validity, key strength, renewal, and behavior when an intermediate certificate is omitted.
• Confirm clients reject an untrusted certificate, hostname mismatch, expired certificate, and incomplete chain in a controlled test environment.
• Check HTTP redirects, HSTS coverage, mixed content, WebSocket security, and cookies marked Secure.
• Trace sensitive requests through each proxy and service hop to confirm encryption does not terminate earlier than intended.
• Review exceptions for business owner, compensating controls, expiration, and an upgrade plan.
• Add certificate-expiration monitoring and automated TLS-policy checks to deployment and external monitoring.

References#

• CWE-326: Inadequate Encryption Strength ↗ (opens in a new tab)cwe.mitre.org
• CWE-327: Use of a Broken or Risky Cryptographic Algorithm ↗ (opens in a new tab)cwe.mitre.org
• RFC 8996: Deprecating TLS 1.0 and TLS 1.1 ↗ (opens in a new tab)rfc-editor.org
• NIST SP 800-52 Rev. 2: Guidelines for TLS Implementations ↗ (opens in a new tab)csrc.nist.gov
• OWASP Transport Layer Security Cheat Sheet ↗ (opens in a new tab)cheatsheetseries.owasp.org
• OWASP Top 10 A02:2021 Cryptographic Failures ↗ (opens in a new tab)owasp.org

Related vulnerabilities#