TLS HTTPS — Cheat Sheet

Tags: tls, https, cryptography, networking, security, ssl, certificates, web

Level: intermediate

TL;DR: TLS secures HTTP traffic by combining asymmetric cryptography for authentication and key exchange with symmetric cryptography for fast payload encryption.

Key concepts

HTTPS is HTTP layered over TLS on TCP port 443.

Asymmetric encryption authenticates servers and safely exchanges keys.

Symmetric encryption encrypts actual application payload efficiently.

TLS 1.3 reduces the handshake to a single round-trip (1-RTT).

Ephemeral Diffie-Hellman provides Forward Secrecy across sessions.

X.509 certificates bind public keys to specific domain identities.

Certificate Authorities form a hierarchical trust chain validated by clients.

SNI sends the target hostname inside the initial Client Hello.

ALPN negotiates application protocols like HTTP/2 within the TLS handshake.

Integrity checks use AEAD ciphers to prevent in-flight tampering.

Typical questions and ready answers

Q: How does a TLS 1.3 handshake work?R: The client sends supported ciphers and key shares in Client Hello; the server responds with its certificate, selected cipher, and key share, enabling encrypted application traffic in just 1-RTT.

Q: What is Forward Secrecy and why is it essential?R: It ensures past session traffic remains confidential even if the server private key is compromised later, by generating unique ephemeral keys per session via Diffie-Hellman.

Q: What purpose does SNI serve?R: Server Name Indication allows multiple virtual hosts with distinct TLS certificates to share a single public IP address by declaring the hostname early.

Q: Why do we use both asymmetric and symmetric encryption in HTTPS?R: Asymmetric encryption securely authenticates the server and establishes shared secrets without prior contact, while symmetric encryption provides the throughput required for data transfer.

Pitfalls and common mistakes

Missing intermediate certificates breaks verification on clients without cached CA bundles.

Ignoring certificate expiry or revocation checks causes sudden production outages.

Terminating TLS at reverse proxies without secure internal upstream links risks internal snooping.

Relying on legacy cipher suites enables downgrade attacks and leaks traffic.

Omitting HSTS headers leaves users vulnerable to SSL-stripping man-in-the-middle attacks.

Snippets and commands

# Inspect TLS certificate chain, validity, and negotiation
openssl s_client -connect example.com:443 -servername example.com

# Verify local certificate dates and subject details
openssl x509 -in cert.pem -noout -text -dates -subject

Nginx

# Minimal modern TLS configuration for Nginx
server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/ssl/certs/fullchain.pem;
    ssl_certificate_key /etc/ssl/private/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

To review

[ ] TLS 1.2 (2-RTT) vs TLS 1.3 (1-RTT and 0-RTT resumption) differences

[ ] OCSP Stapling setup and advantages over standard CRL lookups

[ ] mTLS configuration and mutual client authentication flows

References

RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3

RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2

Mozilla SSL Configuration Generator documentation

Jarvis Interviews
Jarvis