SSL, TLS, and HTTPS
On this page 18
Part III — Networking & protocols · Interview reference
TLS provides confidentiality, integrity, and authentication on top of TCP (or QUIC). Seniors must explain the handshake at a conceptual level, certificate trust, mTLS, and operational failure modes — not recite cipher acronyms without meaning.
Definitions
| Term | Meaning |
|---|---|
| SSL | Obsolete predecessor; term survives colloquially |
| TLS | Modern protocol family (use TLS 1.2+; prefer 1.3) |
| HTTPS | HTTP over TLS |
| Certificate | X.509 binding of public key to identity (hostname), signed by CA |
| CA / chain of trust | Browser/OS trust store → intermediates → leaf |
| SNI | Server Name Indication — which cert to present on shared IP |
| mTLS | Mutual TLS — client also presents a certificate |
| Forward secrecy | Compromise of long-term key doesn’t decrypt past sessions (ECDHE) |
What TLS provides / does not
| Provides | Does not provide by itself |
|---|---|
| Encryption in transit | Authorization / business ACLs |
| Server auth (usual) | End-to-end if terminated at LB/gateway |
| Integrity (tamper detect) | Availability |
| Optional client auth | Protection after decryption (app bugs) |
Handshake (conceptual — TLS 1.2 vs 1.3)
Goals: agree version/ciphers, authenticate server (and optionally client), establish shared secrets.
TLS 1.3 differences seniors should mention:
- Fewer round trips (1-RTT; 0-RTT option with replay caveats)
- Removed legacy ciphers / RSA key transport
- Encrypted more of the handshake
Do not memorize every message name unless interviewing for security engineering; do know: cert validation, RTTs matter for latency, session resumption exists.
Certificates — operational core
Validation checklist
- Hostname matches (SAN / CN rules)
- Not expired / not before
- Chain leads to trusted anchor
- Signature valid; key usage appropriate
- Revocation story (CRL/OCSP) — often weak in practice; short-lived certs help
Common production setups
| Setup | Notes |
|---|---|
| Terminate TLS at LB / API gateway | Backend may be plain HTTP on private net — know trust boundary |
| TLS everywhere (mesh / mTLS) | Stronger identity; operational complexity |
| ACME / Let’s Encrypt / ACM | Automation required; renewal monitoring |
Interview angle: “Where does TLS terminate?” defines who can read plaintext.
Production case study (high volume)
Context: Global SaaS terminates TLS at CloudFront/ALB for a public API (~100M req/day) and uses mTLS (SPIFFE) east-west in EKS for ledger services. Why seniors care: Wrong trust boundary → plaintext on shared networks; cert expiry is a SEV-1; handshake CPU under connection storms dominates first-byte latency. Failure / symptom: Overnight outage from expired leaf/intermediate; clients fail verify after missing intermediate in chain; CPU cliff on origins when keep-alive disabled. Resolution: Automated ACME/ACM renewal + expiry pages; serve full chain; force connection reuse / TLS1.3; separate edge terminate vs mesh identity; alert on handshake rate and cert days-left. Seen at / similar to: Let’s Encrypt expiry incidents industry-wide; Cloudflare Universal SSL; Istio/Linkerd mTLS; AWS ACM + ALB.
mTLS
- Client cert proves client identity to server (machine-to-machine)
- Used in service mesh, bank APIs, private APIs
- Requires cert provisioning/rotation for clients; SPIFFE/SPIRE or mesh identity often appears in senior designs
Production case study (high volume)
Context: Open-banking / partner API (PSD2-style) requires mTLS for every call; thousands of partner certs rotating.
Why seniors care: Pinning without rotation bricks partners; clock skew fails handshakes; 0-RTT replay on non-idempotent POSTs is a security bug.
Failure / symptom: Mass partner failures after CA change; intermittent verify errors (NTP); duplicate POSTs with 0-RTT.
Resolution: Short-lived certs + automation; disable 0-RTT for unsafe methods; monitor handshake failure codes by partner; never InsecureSkipVerify in prod clients.
Seen at / similar to: Stripe Connect / banking open-API platforms; Google ALTS/SPIFFE narratives; Apple App Attest-adjacent partner auth stories.
HTTPS specifics
- Default port 443
- Mixed content (HTTPS page loading HTTP assets) — browser blocks/warns
- HSTS header — force HTTPS (HTTP headers)
- HTTP → HTTPS redirects must be careful with method/body and HSTS preload
Performance
| Factor | Impact |
|---|---|
| Extra RTTs | Handshake latency; mitigate with keepalive, session tickets, TLS1.3, HTTP/2-3 |
| CPU crypto | Usually acceptable; watch bulk throughput / premature termination patterns |
| Cert size / chain length | Extra bytes on handshake |
| OCSP stapling | Improves client-side revocation checks |
Connection reuse is the #1 HTTPS performance lever in microservices.
Production case study (high volume)
Context: Mobile BFF opened a new TLS connection per API call to 15 backends during a Super Bowl ad spike.
Why seniors care: Handshake RTTs multiply into user-visible p99; CPU crypto on origins scales with new conns, not request count.
Failure / symptom: Origin CPU high in SSL_do_handshake; client timeouts; connection pool metrics near empty.
Resolution: HTTP/2 + pooled clients; session tickets; measure handshake vs app time in tracing; load-test with TLS, not plaintext localhost.
Seen at / similar to: Netflix Edge / Zuul; AWS API Gateway + VPC link patterns; Chrome connection coalescing lessons applied server-side.
Security pitfalls (high yield)
- TLS 1.0/1.1, weak ciphers still enabled
- Expired / wrong hostname certs → outages
- Skipping verification in clients (
InsecureSkipVerify) — common footgun - Terminating TLS then sending sensitive data across untrusted networks
- Certificate pinning without rotation plan → bricking clients
- 0-RTT replay risks for non-idempotent requests
- Trusting only network perimeter instead of service identity
Java under the hood (JSSE)
| Piece | Role |
|---|---|
SSLContext | Factory for engines/sockets; init with KeyManager + TrustManager + SecureRandom |
SSLSocket | Blocking TLS over a socket |
SSLEngine | Non-blocking TLS state machine for NIO/Netty — wrap/unwrap ByteBuffers |
| Trust / keys | Default trust store (cacerts); custom TrustManagerFactory / keystores (KeyStore) |
| Hostname verify | HTTPS endpoint identification; disabling = MITM-ready footgun (HostnameVerifier / modern HttpClient SSL params) |
| Algorithms | jdk.tls.disabledAlgorithms / security properties gate weak protocols/ciphers |
| Clients | Prefer java.net.http.HttpClient over legacy HttpsURLConnection |
Handshake CPU and RTTs still dominate first request — connection reuse / HTTP/2 multiplexing matter as much as cipher choice.
Production case study (high volume)
Context: JVM service disabled hostname verification temporarily to “fix” a staging cert issue; change leaked to prod via shared client module.
Why seniors care: MITM-ready clients are silent until abused; seniors treat TLS client config as security-critical code.
Failure / symptom: Often none until audit/pen-test; or intermittent corporate proxy MITM “works” hiding the bug.
Resolution: Custom TrustManager only with pinned/test CA in non-prod; fail closed; CI grep for insecure verifiers; separate prod/stage SSL contexts.
Seen at / similar to: Industry-wide InsecureSkipVerify postmortems; Java HostnameVerifier footguns widely documented.
What interviewers probe
- Difference between SSL and TLS; which versions are acceptable.
- Explain certificate chain validation for
api.example.com. - Where to terminate TLS in a design; tradeoffs with mTLS mesh.
- mTLS vs API keys/JWT for service auth.
- Handshake latency and how HTTP/2 + keepalive help.
- Debug
certificate verify failed— clock skew, missing intermediate, SNI, corporate proxy MITM. - Forward secrecy in one sentence.
- Handshake storms under connection churn at peak QPS.
Senior-level expectation: Clear trust boundaries; operational cert lifecycle; no “just disable verification” fixes.
Pitfalls checklist
- Client disables verify to “unblock prod”
- Missing intermediate CA in server chain
- Idle LB timeout shorter than pooled TLS connections’ lifetime assumptions
- Wildcard cert sprawl / overbroad SANs
- Forgetting clock sync (TLS is time-sensitive)
- Cert expiry without automated renewal alerts
- 0-RTT enabled for non-idempotent payment POSTs