TLS/SSL

1. What Is It?

TLS (Transport Layer Security) is the protocol that encrypts and authenticates network connections. When you see https:// in a URL or a padlock icon in a browser, TLS is running underneath. SSL (Secure Sockets Layer) is TLS's predecessor — they're the same concept, but SSL 2.0 and 3.0 are deprecated and broken; modern systems use TLS 1.2 or TLS 1.3.

TLS solves three problems simultaneously:

1. Confidentiality — data is encrypted so eavesdroppers see ciphertext, not plaintext.
2. Integrity — a message authentication code (MAC) detects tampering in transit.
3. Authentication — certificates prove you're talking to the server you intended, not an impersonator.

Without TLS, any network intermediary between a client and server (ISP, router, Wi-Fi access point) can read credentials, session tokens, and API keys in plaintext.

2. How It Works

TLS 1.3 Handshake (Modern)

TLS 1.3 reduces the handshake to 1 round trip (down from 2 in TLS 1.2):

-+ResetFullscreen

What's in a certificate:

• The server's public key
• The domain name(s) it's valid for (Subject Alternative Names)
• The issuing Certificate Authority (CA)
• Expiry date
• A digital signature from the CA

The client verifies the certificate by checking: (1) the signature against the CA's public key (which the OS/browser ships with), (2) the domain matches what was requested, (3) the certificate hasn't expired, (4) it hasn't been revoked.

Certificate chain of trust: Most servers send an intermediate certificate plus the leaf certificate. The chain goes: root CA (trusted by OS) → intermediate CA → your domain's certificate. Root CAs are embedded in OS and browser trust stores.

Key concepts:

• Asymmetric encryption (RSA/ECDSA) is used during the handshake to securely exchange a symmetric key.
• Symmetric encryption (AES-GCM, ChaCha20-Poly1305) encrypts the actual data — much faster than asymmetric.
• Session resumption (TLS 1.3 0-RTT) — a returning client can send data in the first message using a pre-shared session ticket, reducing latency to 0 extra round trips. Has replay attack caveats (see Tradeoffs).

3. What SDEs Actually Need to Know

Certificate errors and what they mean:

TLS in service-to-service communication: Mutual TLS (mTLS) requires both sides to present certificates, not just the server. Common in service meshes (Istio, Linkerd) where every service-to-service call is authenticated and encrypted. The service mesh often handles cert rotation automatically.

Certificate management:

• Certificates expire. Automate renewal with Let's Encrypt + Certbot, or use ACM (AWS) / Google-managed certs.
• Expiry surprises are one of the most common production incidents. Monitor certificate expiry with alerting (30-day warning is standard practice).

Cipher suites and protocol versions: TLS 1.0 and 1.1 are deprecated (RFC 8996) and disabled by default in modern runtimes. TLS 1.2 is still widely used. TLS 1.3 is preferred — it's faster (1-RTT), removes weak cipher options, and has forward secrecy by default. Many compliance frameworks (PCI-DSS, HIPAA) require TLS 1.2+ and specific cipher suites.

SNI (Server Name Indication): When a server hosts multiple domains on one IP, TLS SNI allows the client to send the hostname in the ClientHello message (before encryption begins) so the server can select the right certificate. Load balancers and CDNs rely on SNI to route HTTPS traffic.

4. Tradeoffs & Decisions

TLS 1.3 0-RTT early data: Allows the client to send data before the handshake completes, at the cost of replay attack vulnerability. A network attacker can replay a captured 0-RTT request. Safe only for idempotent operations (GET requests); never use for mutations or payments without replay protection at the application layer.

Self-signed certs vs. CA-issued certs: Self-signed certs work in development and for internal mTLS (where you control both ends and your own CA), but browsers and most HTTP clients reject them by default. For any user-facing service, use a publicly trusted CA (Let's Encrypt is free). For internal service-to-service, a private CA managed by Vault or AWS Certificate Manager Private CA is appropriate.

Terminating TLS at the load balancer vs. end-to-end:

• TLS termination at LB — decrypts at the load balancer, forwards plaintext internally. Simple, lets the LB inspect traffic, but traffic inside your network is unencrypted.
• TLS passthrough — LB forwards encrypted TCP, TLS terminates at the backend. LB can't inspect or modify HTTP headers (no host-based routing).
• Re-encrypt — LB terminates TLS, then opens a new TLS connection to the backend. Encrypted everywhere; best for compliance-sensitive traffic.

5. Interview Cheat Sheet

Key sentences:

• "TLS provides three things: encryption (confidentiality), MAC verification (integrity), and certificate authentication (server identity)."
• "The TLS 1.3 handshake takes 1 round trip — the client sends key material immediately, so data can flow after just one exchange instead of two."
• "A certificate is trusted if it chains up to a root CA that's in the OS/browser trust store; a self-signed cert breaks this chain."
• "mTLS requires both client and server to present certificates, enabling mutual authentication — the foundation of service mesh security."

Common follow-ups:

Q: What happens after a TLS certificate expires? A: Clients receive a certificate validation error and refuse to connect (or display a security warning). The service is effectively unavailable for HTTPS clients. This is why certificate expiry monitoring and automated renewal (Let's Encrypt, ACM) are essential operational practices.

Q: What is forward secrecy? A: Forward secrecy (or perfect forward secrecy, PFS) means that compromising the server's private key today cannot decrypt previously captured traffic. This is achieved with ephemeral key exchange (ECDHE) — a new key pair is generated per session and discarded after use. TLS 1.3 mandates forward secrecy; TLS 1.2 supports it with ECDHE cipher suites.

Q: What's the difference between TLS termination and TLS passthrough at a load balancer? A: With termination, the LB decrypts the traffic and can inspect/route based on HTTP headers, then optionally re-encrypts to the backend. With passthrough, the LB forwards the raw TLS stream without decrypting, so the backend handles TLS directly — useful when the LB shouldn't see plaintext content, but limits routing capabilities to TCP-level (IP, port) only.