1. What Is It?
(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, 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:
- Confidentiality — data is encrypted so eavesdroppers see ciphertext, not plaintext.
- Integrity — a message authentication code (MAC) detects tampering in transit.
- 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.
A developer builds an internal API that transmits user session tokens over plain HTTP between a mobile client and a backend server. The traffic passes through a corporate Wi-Fi access point. Which security property is most directly at risk because TLS is not being used?
2. How It Works
TLS 1.3 Handshake (Modern)
1.3 reduces the handshake to 1 round trip (down from 2 in 1.2):
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 cryptography is used during the handshake. An ephemeral (EC)DHE key exchange derives the symmetric key. The certificate's RSA/ECDSA key signs the handshake to prove the server's identity.
- 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).
From key shares to encrypted data
The TLS 1.3 handshake exchanges key shares and authenticates the server before the client sends encrypted application data.
The client sends its key share immediately, so the handshake needs only one round trip.
Text version
- The client sends its key share immediately, so the handshake needs only one round trip.
- The server sends its key share, chosen cipher, certificate, CertificateVerify, and Finished.
- The client checks the CA chain, domain, and validity dates, and applies its revocation policy.
- The client verifies CertificateVerify and server Finished before sending its own Finished.
- Symmetric encryption protects application data because it is much faster than asymmetric encryption.
Your backend API handles high-frequency data transfers after the TLS handshake is complete. Why does TLS use asymmetric encryption during the handshake but switch to symmetric encryption (like AES-GCM) for the actual application data?
3. What SDEs Actually Need to Know
Certificate errors and what they mean:
| Error | Cause |
|---|---|
CERTIFICATE_EXPIRED | Certificate's notAfter date passed. Renew it. |
SSL_ERROR_BAD_CERT_DOMAIN | Certificate doesn't include the hostname you requested (SAN mismatch). Common when using an IP address, or a CDN/load balancer with wrong cert routing. |
UNABLE_TO_VERIFY_LEAF_SIGNATURE / CERT_UNTRUSTED | Missing intermediate certificate, or the CA is not trusted. Often seen in corporate environments with a custom root CA. |
SELF_SIGNED_CERT_IN_CHAIN | A self-signed cert in use (dev/testing). Production should never use self-signed certs. |
CERTIFICATE_REVOKED | CA has revoked this cert (compromised key). Rare but serious. |
in service-to-service communication: Mutual (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.
SNI selects the certificate for the hostname
A client includes the hostname in ClientHello so a server hosting multiple domains on one IP can select the right certificate.
The client puts the hostname in ClientHello so the server knows which domain it wants.
Text version
- The client puts the hostname in ClientHello so the server knows which domain it wants.
- The server uses that hostname to select a certificate when several domains share one IP address.
- The server returns the selected certificate so the client can verify the server.
Your team's backend service suddenly starts rejecting HTTPS requests with an SSL_ERROR_BAD_CERT_DOMAIN error after you migrate it behind a new load balancer. What is the most likely cause?
4. Tradeoffs & Decisions
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 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 at the vs. end-to-end:
- TLS termination at LB — decrypts at the , forwards plaintext internally. Simple, lets the LB inspect traffic, but traffic inside your network is unencrypted.
- TLS passthrough — LB forwards encrypted , TLS terminates at the backend. LB can't inspect or modify headers (no path or header routing), but it can still route by the plaintext SNI hostname.
- Re-encrypt — LB terminates TLS, then opens a new TLS connection to the backend. Encrypted everywhere; best for compliance-sensitive traffic.
Protecting the hop after the load balancer
TLS termination can leave the internal hop in plaintext. Re-encryption opens a new TLS connection from the load balancer to the backend.
With TLS termination, the load balancer decrypts client traffic so it can inspect it.
Text version
- With TLS termination, the load balancer decrypts client traffic so it can inspect it.
- The load balancer forwards plaintext, so traffic inside your network is unencrypted.
- With re-encryption, the load balancer still terminates the client's TLS connection.
- It opens a new TLS connection to the backend, protecting traffic on the internal hop.
Your team is deploying a payment service behind a load balancer. The compliance team requires that traffic be encrypted both between the client and the load balancer AND between the load balancer and the backend service. Which TLS termination strategy should you use?
5. Interview Cheat Sheet
Key sentences:
- " provides three things: encryption (confidentiality), MAC verification (integrity), and certificate authentication (server identity)."
- "The 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 ? A: With termination, the LB decrypts the traffic and can inspect/route based on 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. This is useful when the LB shouldn't see plaintext content. But it limits routing to -level data (IP, port) plus the SNI hostname in the ClientHello.