Skip to content

TLS Handshake

1. What is it? (2-3 lines)

The TLS (Transport Layer Security) Handshake is an encryption and authentication protocol executed on top of TCP. It authenticates server identity via X.509 digital certificates, negotiates cipher suites, and securely derives symmetric encryption keys for encrypted communication.

2. Why does it exist?

Raw TCP connections transmit data in plain text, making them vulnerable to network eavesdropping, packet tampering, and Man-In-The-Middle (MITM) attacks. The TLS Handshake establishes an encrypted HTTPS tunnel, guaranteeing Confidentiality (encryption), Integrity (MAC checksums), and Authentication (digital certificates).

3. Where is it used?

  • Web & Mobile Traffic: HTTPS (port 443), WSS (Secure WebSockets).
  • Microservices & Service Mesh: Mutual TLS (mTLS) via Envoy / Istio.
  • Secure Databases: PostgreSQL SSL, MySQL TLS, Redis TLS connections.

4. How does it work? (TLS 1.2 vs TLS 1.3 Flow)

TLS 1.2 Handshake (2 RTT Latency Cost)

  1. ClientHello (Client \(\to\) Server): Supported TLS versions, cipher suites, random number \(C_r\), SNI extension.
  2. ServerHello + Cert (Server \(\to\) Client): Selected cipher suite, random number \(S_r\), X.509 Certificate + Public Key.
  3. Cert Verification & Key Exchange: Client verifies certificate chain via CA root certificates \(\to\) Generates Pre-Master Secret \(\to\) Encrypts with server's Public Key \(\to\) Sends to server.
  4. Session Key Derivation: Both sides derive symmetric Master Secret using \(C_r, S_r,\) and Pre-Master Secret.
  5. Finished (Encrypted): Both sides switch to symmetric AES-GCM encryption (2 RTTs elapsed!).

TLS 1.3 Handshake (1 RTT / 0-RTT Latency Cost)

  1. ClientHello (Client \(\to\) Server): Client sends key share guess (ECDHE Diffie-Hellman) in 1st packet!
  2. ServerHello + Cert + Finished (Server \(\to\) Client): Server responds with its key share, certificate, and Finished MAC in 1 packet!
  3. 1 RTT Complete: Both sides derive symmetric keys immediately. Subsequent connections support 0-RTT Resumption!
TLS 1.3 Flow:
Client                               Server
  | --- ClientHello + Key Share --->   |  (1 RTT Latency Cost!)
  | <-- ServerHello + Cert + Finish -- |  [Encrypted Tunnel Active]
  | === Encrypted Application Data ===> |

5. Advantages

  • Robust zero-trust security: Confidentiality (AES-GCM), Integrity (HMAC), Authentication (RSA/ECC).
  • TLS 1.3 cuts handshake latency in half (from 2 RTT to 1 RTT, and 0-RTT for returning connections).
  • Perfect Forward Secrecy (PFS): Compromising server's long-term private key cannot decrypt past recorded sessions.

6. Limitations

  • Added Latency: Adds 1 RTT (TLS 1.3) or 2 RTT (TLS 1.2) on top of TCP 3-Way Handshake latency.
  • CPU Overhead: Asymmetric RSA/ECC math during key exchange requires CPU computation (accelerated via AES-NI / hardware crypto offload).

7. Common interview questions (10)

  1. Walk through the architectural latency differences between TLS 1.2 (2 RTT) and TLS 1.3 (1 RTT).
  2. How does Perfect Forward Secrecy (PFS) work and why is Ephemeral Diffie-Hellman (ECDHE) required?
  3. What is ALPN (Application-Layer Protocol Negotiation) and how does it negotiate HTTP/2 vs HTTP/1.1 during TLS setup?
  4. What is SNI (Server Name Indication) and why is it mandatory for hosting multiple SSL domains on 1 IP address?
  5. How does Mutual TLS (mTLS) differ from standard One-Way TLS in microservice architectures?
  6. What is 0-RTT Resumption in TLS 1.3 and what security risk (Replay Attacks) does it introduce?
  7. How does X.509 Certificate Chain of Trust verification work (Root CA \(\to\) Intermediate CA \(\to\) Leaf Cert)?
  8. What is OCSP Stapling and how does it prevent blocking certificate revocation checks?
  9. Why are RSA Key Exchanges deprecated in TLS 1.3 in favor of ECDHE?
  10. How does hardware acceleration (Intel AES-NI / ARM Crypto) optimize TLS throughput?

8. Common misconceptions

  • Misconception: Symmetric encryption (AES) is used for the entire handshake. Fact: Asymmetric encryption (RSA/ECC) is used only during the handshake to negotiate keys; fast Symmetric encryption (AES-GCM) encrypts actual application data.
  • Misconception: TLS 1.3 requires 2 RTTs like TLS 1.2. Fact: TLS 1.3 combines key exchange with ClientHello, establishing encrypted channels in just 1 RTT.

10. 30-second cheat sheet

  • TLS 1.2: 2 RTT Handshake (Asymmetric Key Exchange \(\to\) Derive Symmetric Keys).
  • TLS 1.3: 1 RTT Handshake (Sends ECDHE Key Share in 1st ClientHello packet!). Supports 0-RTT Resumption.
  • Cipher Standard: AES-256-GCM (Symmetric data bulk encryption) + ECDHE (PFS Key Exchange).
  • Microservices: Use mTLS (Mutual X.509 cert validation) for zero-trust East-West service communication.