When someone says "we have SSL," they usually mean they installed a certificate and their site loads over HTTPS. That's the starting line, not the finish line. The security of a TLS connection depends on protocol versions, cipher suite selection, key exchange parameters, certificate chain configuration, and a set of complementary headers and policies that most deployments get wrong. A certificate without proper configuration is like a deadbolt on an unlocked door — it looks secure but provides far less protection than expected.
Protocol Versions: Why TLS 1.0 and 1.1 Must Die
TLS has evolved through several versions, each addressing vulnerabilities in its predecessors. The current landscape:
- SSL 2.0 and 3.0: Broken beyond repair. POODLE and DROWN attacks make these protocols actively dangerous. No modern browser supports them, and enabling them on your server creates risk with zero benefit.
- TLS 1.0: Deprecated since 2020 by all major browsers. Vulnerable to BEAST and other attacks. PCI DSS explicitly prohibits it for payment processing.
- TLS 1.1: Also deprecated. Marginally better than 1.0 but lacks modern cryptographic features and is considered insufficient by current standards.
- TLS 1.2: The current baseline. When properly configured with strong cipher suites, it provides robust security. Still the most widely deployed version.
- TLS 1.3: The gold standard. Faster handshake (one fewer round trip), removed all weak cipher suites by design, and eliminated classes of attacks that plagued earlier versions. There's no reason not to support it.
Your server should support TLS 1.2 and TLS 1.3 only. Every older protocol version you keep enabled is an attack surface with documented exploit techniques. The "but what about legacy clients" argument rarely survives scrutiny — the vanishingly small percentage of clients that only support TLS 1.0 are themselves security risks that shouldn't be connecting to your infrastructure.
Cipher Suite Selection
Even within TLS 1.2, not all connections are equal. The cipher suite determines the algorithms used for key exchange, authentication, encryption, and integrity. A weak cipher suite can make a TLS 1.2 connection less secure than a well-configured TLS 1.3 connection.
The principles for cipher suite selection:
- Forward secrecy is mandatory: Cipher suites using ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) or DHE key exchange provide forward secrecy, meaning that compromising the server's private key doesn't compromise past sessions. Without forward secrecy, an attacker who records encrypted traffic can decrypt it all if they later obtain the private key.
- AES-GCM over CBC: GCM (Galois/Counter Mode) provides authenticated encryption. CBC (Cipher Block Chaining) mode has been the target of multiple attacks (Lucky13, BEAST) and requires careful implementation to avoid timing side-channels.
- Remove weak algorithms: RC4 is broken. 3DES is deprecated. Export-grade ciphers are trivially weak. MD5 for integrity is compromised. Any cipher suite containing these algorithms should be disabled.
- CHACHA20-POLY1305: An excellent alternative to AES-GCM, particularly on devices without hardware AES acceleration. Recommended alongside AES-GCM for broad compatibility with strong security.
TLS 1.3 solved the cipher suite problem by removing all weak options. Only five cipher suites are defined, and all provide forward secrecy and authenticated encryption. This is one of its most important improvements — it's impossible to misconfigure TLS 1.3 cipher suites because there are no bad options to choose from.
HSTS: The Header That Prevents Downgrade
HTTPS is only effective if it's actually used. Without HSTS (HTTP Strict Transport Security), the first request a user makes is often over HTTP — either because they typed the URL without https://, clicked an old bookmark, or followed a link that specifies HTTP. That initial HTTP request is interceptable on any untrusted network.
HSTS tells the browser: "Never connect to this domain over HTTP. Always use HTTPS, even if the user or a link explicitly requests HTTP." Once the browser receives the HSTS header, all subsequent connections are HTTPS — no HTTP request, no redirect, no interception window.
Critical HSTS configuration details:
- max-age: Set to at least 31536000 (one year). Shorter values leave gaps where the policy expires and the downgrade window reopens.
- includeSubDomains: Apply HSTS to all subdomains. Without this, a subdomain can be loaded over HTTP, and cookies with broad domain scope can be intercepted.
- preload: Submit your domain to the browser's HSTS preload list. This hardcodes HTTPS-only behaviour into the browser itself, eliminating even the first-visit vulnerability. Once preloaded, there is never an HTTP connection — not even the very first one.
HSTS preloading is a serious commitment. Removing a domain from the preload list takes months. Ensure every subdomain supports HTTPS before preloading, because the browser will refuse HTTP connections to all of them.
Certificate Management Beyond Installation
Certificate management is an ongoing operational task, not a one-time setup:
- Automated renewal: Let's Encrypt certificates expire every 90 days by design — to encourage automation. Manual renewal processes inevitably fail, causing outages and security warnings. Use certbot, ACME clients, or your cloud provider's automated certificate management.
- Certificate chain completeness: Your server must send the full certificate chain — your leaf certificate plus all intermediate certificates. A missing intermediate causes validation failures on some clients but not others, creating intermittent errors that are difficult to diagnose.
- Key rotation: Private keys should be rotated periodically and immediately if compromise is suspected. Using different keys for each certificate renewal is good practice.
- Certificate Transparency monitoring: CT logs record every certificate issued for your domain. Monitoring these logs alerts you if a certificate authority issues a certificate for your domain that you didn't request — a sign of domain validation compromise or CA misissuance.
OCSP Stapling
When a browser receives your certificate, it needs to check whether the certificate has been revoked. The traditional method — querying the CA's OCSP responder — adds latency to every connection and leaks user browsing data to the CA. OCSP stapling lets your server fetch the revocation status periodically and include (staple) the signed response in the TLS handshake. The browser gets a fresh revocation check without contacting the CA.
Without OCSP stapling, some browsers fall back to "soft fail" — if they can't reach the OCSP responder, they assume the certificate is valid. This means a revoked certificate might still be accepted if the CA is unreachable, which is exactly the scenario an active attacker could engineer.
The Configuration Drift Problem
TLS configuration isn't set-and-forget. Security standards evolve, new attacks emerge, and cipher suites that were acceptable two years ago may be deprecated today. Certificate expiration dates creep closer. New subdomains are added without inheriting the parent domain's TLS hardening. Server software updates can reset configuration to defaults.
Without continuous monitoring, TLS configurations degrade over time. What scored an A on SSL Labs six months ago might score a B today due to updated grading criteria or newly deprecated cipher suites. The configuration that was secure at deployment isn't guaranteed to remain secure through drift and neglect.
ShieldReport continuously monitors your domain's TLS configuration — protocol versions, cipher suites, certificate validity, HSTS deployment, and supporting headers — alerting you to degradation before it becomes an exploitable weakness.