TLS/SSL Handshake & Encryption Basics

Cryptography in system design uses Hybrid Encryption:

1. Asymmetric Cryptography (RSA / ECC / ECDHE): Slow and compute-heavy (RSA-4096 encryption is ~1000x slower than AES-256). Used only during the handshake to verify identity and securely negotiate a shared secret. RSA-2048 operations take ~1ms on modern hardware; ECDHE (Elliptic Curve) is 40-100x faster than RSA at equivalent security levels.
2. Symmetric Cryptography (AES-256-GCM / ChaCha20-Poly1305): Extremely fast hardware-accelerated stream ciphers. AES-NI CPU instructions encrypt at ~1-10 GB/s. Used for all actual payload data transfer after the handshake.

Forward Secrecy (PFS) guarantees that even if an attacker steals a server's private RSA certificate key in the future, they cannot retroactively decrypt recorded past network traffic. ECDHE generates temporary (ephemeral) session keys discarded immediately after the session ends.

How ECDHE works conceptually:

• Client picks random private value a, computes public value A = g^a mod p
• Server picks random private value b, computes public value B = g^b mod p
• Both exchange public values and independently compute the same shared secret: S = B^a mod p = A^b mod p = g^(ab) mod p
• This shared secret becomes the session encryption key — it never travels over the network

With ECDHE, each session has a unique, temporary key. Even compromising the server's certificate private key only allows forging future certificates — not decrypting the terabytes of past recorded traffic.

• TLS 1.2: Required 2 full round trips (2-RTT) to negotiate keys. Supported dozens of legacy cipher suites including weak RC4, 3DES, and static RSA key exchange (no Forward Secrecy).
• TLS 1.3: Drops handshake to 1-RTT by sending key guesses in the initial ClientHello. Removed all weak cipher suites — only ECDHE with AES-GCM/ChaCha20 allowed.
• 0-RTT Resumption: Returning clients can send encrypted data in the very first packet using a pre-shared session ticket from the previous connection.

0-RTT Replay Attack Risk: The 0-RTT mechanism does not prevent replay attacks — an attacker could capture and re-send the first flight of 0-RTT data. Safe only for idempotent GET requests. Never use 0-RTT for POST/PUT/DELETE operations that have side effects. Mitigated server-side with anti-replay caches.

An X.509 certificate ties a public key to an identity (domain name) using a digital signature from a trusted Certificate Authority (CA). Browsers ship with a hardcoded list of ~150 trusted Root CAs.

Certificate Chain (Chain of Trust):

code
Copy
Root CA (self-signed, stored in browser)
  └── Intermediate CA (signed by Root)
        └── End-Entity Certificate (signed by Intermediate)
              └── api.example.com public key

Why intermediates? Root CA private keys are stored in air-gapped HSMs (Hardware Security Modules). Intermediates allow day-to-day signing without exposing the root key. If an intermediate is compromised, only that sub-tree needs revocation.

Certificate Revocation: If a private key is stolen, the certificate must be revoked before expiry:

• CRL (Certificate Revocation List): Browsers download a list of revoked serial numbers. Updated infrequently; can be stale.
• OCSP (Online Certificate Status Protocol): Browser queries the CA's OCSP responder in real-time to check if the specific cert is revoked. Adds latency.
• OCSP Stapling: Server pre-fetches its own OCSP response and staples it to the TLS handshake. Eliminates the client's OCSP round trip — the best of both worlds.