TLS

Reference notes.

TLS (Transport Layer Security) encrypts communication between two parties, providing confidentiality (encryption), authentication (certificates), and integrity (tamper detection). It’s the “S” in HTTPS.

TLS 1.3 vs 1.2

TLS 1.3 (RFC 8446, 2018) is a major simplification over TLS 1.2.

Aspect	TLS 1.2	TLS 1.3
Handshake round trips	2-RTT	1-RTT (0-RTT resumption)
Cipher suites	Many (including weak ones)	5 strong suites only
Key exchange	RSA or DHE	DHE/ECDHE only (forward secrecy mandatory)
Removed	—	RSA key exchange, RC4, DES, 3DES, MD5, SHA-1, CBC mode, static DH, compression
Encryption	After handshake	From ServerHello onwards

TLS 1.0 and 1.1 are deprecated (RFC 8996). TLS 1.2 remains widely supported but 1.3 should be preferred.

The TLS 1.3 Handshake

Client                               Server
  |--- ClientHello ------------------>|    Supported versions, cipher suites,
  |    + key_share (ECDHE)            |    key share (client's DH public value)
  |                                   |
  |<-- ServerHello -------------------|    Chosen cipher suite, key share
  |    + key_share (ECDHE)            |    (server's DH public value)
  |<-- {EncryptedExtensions} ---------|    Everything encrypted from here
  |<-- {Certificate} -----------------|    Server's certificate chain
  |<-- {CertificateVerify} -----------|    Signature proving possession of key
  |<-- {Finished} --------------------|    Handshake MAC
  |                                   |
  |--- {Finished} ------------------->|    Client's handshake MAC
  |                                   |    Application data can flow

The key exchange happens in the first flight — the client speculatively sends its key share in ClientHello. This is why TLS 1.3 needs only 1 RTT (vs 2 in TLS 1.2).

0-RTT Resumption

On repeat connections, the client can send application data alongside ClientHello using a pre-shared key from a previous session. Saves one full round trip but is not replay-safe — the server cannot guarantee 0-RTT data isn’t replayed. Only safe for idempotent requests (GET, not POST).

Certificates

Certificate Chain

Root CA (self-signed, trusted by OS/browser)
  └── Intermediate CA (signed by root)
        └── Leaf certificate (signed by intermediate, for your domain)

Browsers trust ~150 root CAs pre-installed in their trust store. The server sends the leaf + intermediate(s); the client validates the chain up to a trusted root. Root certificates are never sent — they’re already trusted locally.

Certificate Contents

Subject — Domain name(s) the certificate covers
Subject Alternative Names (SANs) — Additional domains (modern standard, replaced CN matching)
Issuer — The CA that signed it
Validity period — Not Before / Not After
Public key — For key exchange or signature verification
Signature — CA’s signature over the certificate

Certificate Formats

Format	Encoding	Extension	Contains
PEM	Base64 (ASCII)	.pem, .crt, .key	Cert, key, or chain
DER	Binary	.der, .cer	Single cert
PKCS#12	Binary	.p12, .pfx	Cert + key bundle

PEM is the most common on Linux. PKCS#12 is common on Windows and for importing into browsers.

Let’s Encrypt and ACME

Let’s Encrypt provides free, automated certificates using the ACME protocol (RFC 8555). The client proves domain control via:

HTTP-01 — Place a file at http://domain/.well-known/acme-challenge/
DNS-01 — Create a specific DNS TXT record (supports wildcards)

Certificates are valid for 90 days, encouraging automation. Tools: certbot, acme.sh, Caddy (built-in ACME).

Cipher Suites

TLS 1.3 has only 5 cipher suites (all AEAD):

Cipher Suite	Key Exchange	Encryption	Hash
TLS_AES_256_GCM_SHA384	ECDHE	AES-256-GCM	SHA-384
TLS_AES_128_GCM_SHA256	ECDHE	AES-128-GCM	SHA-256
TLS_CHACHA20_POLY1305_SHA256	ECDHE	ChaCha20-Poly1305	SHA-256
TLS_AES_128_CCM_SHA256	ECDHE	AES-128-CCM	SHA-256
TLS_AES_128_CCM_8_SHA256	ECDHE	AES-128-CCM-8	SHA-256

AES-GCM is fastest on hardware with AES-NI (most modern x86 CPUs). ChaCha20-Poly1305 is faster on devices without AES hardware acceleration (mobile, IoT).

Forward Secrecy

TLS 1.3 mandates ephemeral key exchange (ECDHE). Each connection generates a unique session key. If the server’s long-term private key is later compromised, past sessions remain protected. TLS 1.2 with RSA key exchange lacked this — one compromised key decrypts all past traffic.

Key Exchange Algorithms

ECDHE — Elliptic Curve Diffie-Hellman Ephemeral. Most common. Curve X25519 is the default in most implementations.
DHE — Classical Diffie-Hellman Ephemeral. Slower, larger keys. Rare in modern deployments.
RSA — Removed in TLS 1.3. No forward secrecy (server’s static private key decrypts all sessions).

mTLS (Mutual TLS)

Standard TLS only authenticates the server. mTLS requires both sides to present certificates. The server sends a CertificateRequest message, and the client responds with its own certificate and proof of key possession.

Use cases:

Service-to-service authentication in microservices (Istio, Linkerd, Cilium)
API authentication (replacing API keys)
Zero-trust networking

Certificate Revocation

When a private key is compromised, the certificate must be revoked:

CRL (Certificate Revocation List) — CA publishes a list of revoked certificates. Clients download and check. Scales poorly.
OCSP (Online Certificate Status Protocol) — Client queries the CA in real time. Adds latency and a privacy leak (CA knows which sites you visit).
OCSP Stapling — Server fetches its own OCSP response and includes it in the TLS handshake. No extra round trip, no privacy issue. Preferred approach.
Certificate Transparency (CT) — Public, append-only logs of all issued certificates. Enables detection of mis-issued certificates. Required by Chrome for all publicly trusted certificates.

Post-Quantum Cryptography

Quantum computers threaten current key exchange (ECDHE) and signatures (RSA, ECDSA). The risk: “harvest now, decrypt later” — adversaries record encrypted traffic today and decrypt it when quantum computers are available.

NIST PQC Standards (2024)

ML-KEM (CRYSTALS-Kyber) — Post-quantum Key Encapsulation Mechanism. FIPS 203.
ML-DSA (CRYSTALS-Dilithium) — Post-quantum digital signatures. FIPS 204.
SLH-DSA (SPHINCS+) — Hash-based signatures. FIPS 205.

Hybrid Key Exchange

The current approach combines classical and post-quantum algorithms: X25519MLKEM768 (X25519 + ML-KEM-768). If either algorithm is broken, the other still protects the connection. Supported by default in Chrome and Firefox as of mid-2025. Safari support expected with macOS 26 / iOS 26.

IETF Work

Hybrid Key Exchange in TLS 1.3 — IETF draft for combining classical and PQC key exchange

Common Issues

Issue	Cause	Fix
Certificate expired	Auto-renewal failed	Check certbot timer, use `openssl x509 -enddate`
Certificate mismatch	Wrong cert for domain	Check SANs, ensure correct cert is served
Mixed content	HTTP resources on HTTPS page	Update all resource URLs to HTTPS
SNI issues	Old clients, wrong server config	Check `ssl_server_name` / virtual host config
Weak cipher	Legacy TLS 1.0/1.1 or weak suites	Disable old protocols, audit cipher config
HSTS issues	Strict-Transport-Security misconfigured	Start with short max-age, test before includeSubdomains

CLI Tools

# View certificate details
openssl s_client -connect example.com:443 -servername example.com
 
# Check certificate expiry
openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates
 
# Test TLS configuration
nmap --script ssl-enum-ciphers -p 443 example.com
 
# Check certificate chain
openssl s_client -connect example.com:443 -showcerts

SSL Labs Server Test is the standard tool for auditing a server’s TLS configuration.

Rai Notes

Explorer

TLS