Handshake, Certificates & TLS 1.3

What TLS provides

TLS (successor to SSL) gives confidentiality (encryption), integrity (tamper detection), and authentication (server identity via certificates). HTTP runs inside TLS application data records — that's HTTPS.

TLS 1.3 handshake (simplified)

1. ClientHello — supported versions, cipher suites, key shares (ECDHE), SNI hostname.
2. ServerHello — chosen parameters, certificate chain, key share.
3. Client validates chain against trusted CAs, derives session keys.
4. Encrypted application data — typically 1-RTT for a full handshake (TLS 1.3 removed obsolete steps from 1.2).

Certificate chain validation

Server sends leaf cert + intermediates. Client trusts roots in its store, builds a chain leaf → … → trusted root, checks hostname (SAN), expiry, and revocation if configured. SNI lets one IP host many TLS sites — the client sends the hostname in ClientHello.

Session resumption & 0-RTT

Resumption (tickets/PSK) skips full handshake on repeat visits — big win for latency.

0-RTT sends early data before round-trip completes — but it's replayable. Never use 0-RTT for non-idempotent requests (POST that charges a card). Know the trade-off; don't deep-dive cipher politics unless asked.

mTLS (one sentence)

Mutual TLS — client also presents a certificate. Common for service-to-service in zero-trust meshes; operational cost is cert rotation and PKI. Mention when designing internal APIs, not as default for public web.

Interview symptoms → TLS

• Cert expired → hard fail in browsers
• Hostname mismatch → works with curl -k, fails in prod
• Mixed content → browser blocks HTTP subresources on HTTPS page
• TLS termination at LB → backend may be plain HTTP inside VPC (know where encryption ends)