Menu

Earn Premium with Referrals

Invite your friends and earn Premium rewards through our referral program.

See how it works and start inviting friends.

TLS/SSL Handshake Deep Dive
CN

TLS/SSL Handshake Deep Dive

A detailed look at the TLS handshake process, ciphersuites, and key exchange mechanisms.

TLS 1.2 Full Handshake

Client                                      Server
  │── ClientHello ──────────────────────→
  │   (TLS 1.2, ciphersuites, random_nonce)
  │
  │←─ ServerHello ─────────────────────────
  │   (chosen ciphersuite, server random)
  │←─ Certificate ─────────────────────────
  │   (X.509 cert chain ending in trusted root CA)
  │←─ ServerKeyExchange ────────────────────
  │   (ECDHE params: server's ephemeral public key)
  │←─ ServerHelloDone ─────────────────────
  │
  │── ClientKeyExchange ────────────────→
  │   (client's ephemeral public key for ECDHE)
  │── ChangeCipherSpec ────────────────→
  │── Encrypted Finished ──────────────→
  │   (hash of all handshake messages)
  │
  │←─ ChangeCipherSpec ─────────────────────
  │←─ Encrypted Finished ───────────────────
  │
  │         Application Data (AES encrypted)

TLS 1.3 — 1-RTT Handshake

Client                                      Server
  │── ClientHello + KeyShare ───────────→
  │   (supported ciphers, client's ECDHE key)
  │←─ ServerHello + KeyShare + Finished ────
  │   (chosen cipher, server's ECDHE key)
  │── Finished ──────────────────────────→
  │         Application Data immediately

TLS 1.3 eliminates the Certificate + ServerKeyExchange + ClientKeyExchange round trips by having the client send its key share in the initial ClientHello.

Ciphersuite

A ciphersuite is a combination of algorithms used in TLS:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
│     │     │         │         │
│     │     │         │         └── HMAC hash for Finished messages
│     │     │         └──────────── Symmetric cipher + mode
│     │     └──────────────────── Certificate signature algorithm
│     └────────────────────────── Key exchange algorithm
└──────────────────────────────── Protocol

Forward Secrecy

With ephemeral Diffie-Hellman (DHE/ECDHE), the session key is derived from temporary keys that are destroyed after the session. Even if the server’s long-term private key is compromised in the future, past session keys cannot be recovered. TLS 1.3 requires forward secrecy.

Q: What happens during the TLS handshake?

A: Client and server agree on a ciphersuite, exchange cryptographic parameters, authenticate the server via its certificate, and derive a symmetric session key. In TLS 1.2 this takes 2 round trips; in TLS 1.3, just 1.

Q: What is a ciphersuite?

A: A combination of algorithms: key exchange (e.g., ECDHE), authentication (e.g., RSA), symmetric cipher (e.g., AES-256-GCM), and hash (e.g., SHA-384). The client lists supported suites; the server picks one.

Q: What is forward secrecy?

A: Even if the server’s long-term private key is stolen later, past sessions remain secure. Achieved by using ephemeral key exchange (ECDHE) — the session key is derived from temporary keys that are discarded after the session ends. TLS 1.3 mandates forward secrecy.

Q: What is the difference between TLS and SSL?

A: SSL (1.0, 2.0, 3.0) is deprecated and insecure. TLS 1.0-1.3 are the modern standards. “SSL” is commonly used as a generic term, but all secure sites use TLS. TLS 1.2 and 1.3 are the only versions recommended today.

My Private Notes

Notes are auto-saved locally to this device.