Transport Layer Security (TLS)

What it is

TLS is the standard protocol for protecting traffic in transit. HTTPS is HTTP over TLS. It provides confidentiality via encryption, integrity via MACs, and authenticity via certificates (see security:pki).

Why it matters

Without TLS, credentials, cookies (see security:http-sessions-cookies) and application data traverse networks as plaintext, enabling interception and tampering. Weak versions (SSLv3, TLS 1.0/1.1) and weak ciphers are known attack surfaces (e.g., POODLE, BEAST).

How it works

• Handshake: client and server negotiate protocol version and cipher suite, authenticate the server via its certificate chain, and derive session keys.
• TLS 1.3 (RFC 8446) removes legacy ciphers and obsolete key exchange, shortening the handshake and reducing attack surface. Prefer it over TLS 1.2.
• Certificate validation: the peer must present a chain to a trusted root and the hostname must match the certificate (see security:pki).

Detection

• Downgrade to legacy TLS/plaintext on a previously HTTPS-only endpoint.
• Invalid/expired/mismatched certificate warnings.
• Mixed-content pages where secure and insecure resources are loaded together.

Mitigation

• Enforce TLS 1.2+, prefer 1.3; disable SSLv3 and TLS 1.0/1.1.
• Disable weak ciphers and expiring signature algorithms (SHA-1).
• Redirect HTTP to HTTPS and set HSTS; validate certificates and hostnames in every client.
• Never disable validation to “make it work” — this is exactly what interception attacks exploit.

Investigation

For a suspected man-in-the-middle or interception incident, inspect certificate chains, protocol/version negotiation logs, and whether a fixed cert pinned by the client changed unexpectedly. See guides:tool-email-header-guide for seeing TLS and sending-MTA trust in email headers.