TLS & SSL Guide

1. How TLS Works

When a browser connects to https://example.com, TLS establishes a secure channel before any HTTP data is exchanged. This happens in a process called the TLS handshake:

1. Client Hello — The browser sends a list of TLS versions it supports and a list of cipher suites it can use, along with a random value.
2. Server Hello — The server selects the highest mutually supported TLS version and cipher suite, sends its own random value, and presents its digital certificate.
3. Certificate verification — The browser verifies that the certificate was issued by a trusted Certificate Authority (CA), has not expired, and matches the hostname being accessed.
4. Key exchange — Both parties use the negotiated cipher suite to derive a shared symmetric session key without ever transmitting the key itself over the network. Modern TLS uses Diffie-Hellman Ephemeral (DHE) or Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) for this step, which provides forward secrecy.
5. Encrypted session — All subsequent HTTP requests and responses are encrypted using the derived session key, typically AES-GCM or ChaCha20-Poly1305.

Forward secrecy is a critical property: even if an attacker records your encrypted traffic today and later steals your server’s private key, they cannot decrypt previously recorded sessions. ECDHE key exchange (used by TLS 1.3 by default) provides forward secrecy; RSA key exchange (used in older configurations) does not.

2. TLS Versions CRITICAL if 1.0 or 1.1 enabled

TLS has gone through several major versions, each addressing weaknesses in the previous design. Which version your server supports and what it accepts from clients determines your baseline security.

Version	Status	Notes
SSL 2.0	✕ Broken	Completely broken; DROWN attack (CVE-2016-0800). Disabled by default everywhere.
SSL 3.0	✕ Broken	Vulnerable to POODLE (CVE-2014-3566). Disabled by default everywhere.
TLS 1.0	✕ Deprecated	RFC 8996 (2021) formally deprecated. Vulnerable to BEAST, POODLE-TLS. Disabled in all major browsers.
TLS 1.1	✕ Deprecated	RFC 8996 (2021) formally deprecated. Removed from Chrome, Firefox, Safari, Edge.
TLS 1.2	✓ Acceptable	Current minimum standard when configured with strong cipher suites. PCI DSS requires TLS 1.2 minimum.
TLS 1.3	✓ Preferred	Faster handshake (1 round-trip vs 2), mandatory forward secrecy, removed legacy cipher suites. Best choice for all new deployments.

SPAT flags TLS 1.0 or TLS 1.1 support as a HIGH severity finding. Even if modern clients never negotiate these versions, leaving them enabled exposes users in downgrade scenarios where an attacker forces negotiation of the weakest mutually supported version.

nginx configuration to enforce TLS 1.2+ only:

ssl_protocols TLSv1.2 TLSv1.3;

Apache configuration:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

3. Certificate Validity

A TLS certificate serves as cryptographic proof of identity — it binds a public key to a domain name, signed by a Certificate Authority that browsers trust. An invalid or misconfigured certificate is as dangerous as having no TLS at all, because users must click through browser warnings to reach the site, training them to ignore security signals.

What SPAT checks in your certificate:

• Expiry date — Certificates expiring within 30 days trigger a HIGH warning; expired certificates are CRITICAL. Let’s Encrypt certificates expire every 90 days by design — automate renewal with Certbot or ACME clients to avoid this.
• Trusted issuer chain — The certificate must chain to a CA in the browser’s trust store. Self-signed certificates cause "Not Secure" browser warnings and are CRITICAL for any public-facing site.
• Hostname match — The Subject Alternative Name (SAN) or Common Name (CN) must match the domain being accessed. A certificate for www.example.com does not cover example.com unless both are listed in the SAN.
• Certificate type — Domain Validation (DV) is the minimum (verifies domain ownership). Organization Validation (OV) adds business identity verification. Extended Validation (EV) adds the strongest verification but provides minimal additional browser UI treatment in modern browsers.

Getting a free valid certificate:

Let’s Encrypt provides free, browser-trusted DV certificates with automated renewal. Certbot is the recommended ACME client for Apache and nginx on Linux. Cloudflare, AWS Certificate Manager, and most major hosting platforms offer free certificates for domains they manage.

# Install Certbot and obtain a certificate (Ubuntu/Debian)
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

# Verify automatic renewal is scheduled
sudo certbot renew --dry-run

4. Cipher Suites

A cipher suite is a named combination of algorithms used in a TLS connection: a key exchange algorithm, a bulk encryption algorithm, and a message authentication code (MAC). The server and client negotiate a single cipher suite during the TLS handshake from their respective lists of supported suites.

Strong cipher suites (TLS 1.2):

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305

These all use ECDHE (forward secrecy) and AEAD encryption modes (GCM, POLY1305). TLS 1.3 removes cipher suite negotiation complexity — only AEAD cipher suites are permitted, so there is no risk of weak cipher selection when TLS 1.3 is used.

Weak cipher suites to disable:

• Any cipher containing NULL, EXPORT, RC4, DES, 3DES, or MD5
• Suites using RSA key exchange (no forward secrecy) — e.g. AES256-SHA without ECDHE/DHE prefix
• Suites using DHE with parameters smaller than 2048 bits (vulnerable to Logjam)

nginx cipher configuration:

ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

ssl_prefer_server_ciphers off in TLS 1.3 lets the client choose the preferred cipher, which is the recommended setting since modern clients choose well.

5. Common TLS Misconfigurations

Missing HTTP → HTTPS redirect HIGH

If your server accepts plain HTTP connections without redirecting to HTTPS, users who type or click HTTP links get an unencrypted connection. An attacker between the user and server can read and modify all traffic. Redirect all HTTP to HTTPS with a 301 (permanent) redirect. Never use a 302 (temporary) redirect for this purpose — browsers do not cache 302 redirects and do not enforce HSTS based on them.

# nginx
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Mixed content MEDIUM

An HTTPS page that loads resources (images, scripts, stylesheets) via HTTP is serving "mixed content." Browsers block active mixed content (scripts and iframes) and warn on passive mixed content (images). Mixed content arises when CMS content or templates contain hardcoded HTTP URLs. Fix by changing all resource URLs to HTTPS or protocol-relative (//example.com/).

Certificate not covering all served hostnames CRITICAL

A certificate for www.example.com that does not include example.com in the SAN list will produce a certificate error for users hitting the apex domain. Always include both example.com and www.example.com in your certificate’s SAN list. Modern CAs and Certbot do this automatically when you specify multiple -d arguments.

OCSP stapling not configured

OCSP (Online Certificate Status Protocol) lets browsers check whether a certificate has been revoked. Without OCSP stapling, browsers must make a real-time request to the CA’s OCSP server on each new TLS connection, adding latency and a privacy concern (the CA learns which sites users visit). OCSP stapling has the server pre-fetch and cache the OCSP response, delivering it during the TLS handshake. Enable it in nginx with ssl_stapling on; ssl_stapling_verify on;.

6. Configuration Checklist

• ✓ Only TLS 1.2 and TLS 1.3 enabled; TLS 1.0 and 1.1 explicitly disabled
• ✓ Certificate valid, not expired, issued by trusted CA, covering all served hostnames
• ✓ Certificate auto-renewal configured (e.g. Certbot systemd timer)
• ✓ Only ECDHE/DHE cipher suites (forward secrecy); no RC4, NULL, EXPORT, DES, 3DES
• ✓ HTTP → HTTPS 301 redirect on all domains and subdomains
• ✓ HSTS header with max-age ≥ 31536000
• ✓ OCSP stapling enabled
• ✓ No mixed content (all resources loaded over HTTPS)

Use SPAT’s free scanner to check your domain’s TLS configuration now, or see the HTTP Security Headers guide for the next layer of defense.