Computer Science: The Anatomy of TLS 1.3 vs TLS 1.2 Handshakes

Every millisecond of every day, billions of devices transmit credit card numbers, confidential passwords, and private messages across the open internet. The underlying physical medium—submarine fiber optic cables, cell towers, and public coffee shop Wi-Fi routers—is completely accessible to anyone with network sniffing hardware.

How can two strangers who have never met—your web browser in New Delhi and a web server in California—communicate with airtight secrecy across an untrusted wire without a third party eavesdropping?

The answer is Transport Layer Security (TLS), the cryptographic backbone powering HTTPS. In this edition, we explore how modern TLS 1.3 slashed latency in half compared to TLS 1.2, and how both protocols utilize the elegant mathematical machinery of Elliptic-Curve Diffie-Hellman Ephemeral (ECDHE) to defend your data against interception.

1. The Diffie-Hellman Mathematical Miracle

Invented by Whitfield Diffie and Martin Hellman in 1976 (and modernized via Elliptic Curves), Diffie-Hellman solves the ancient Key Distribution Problem.

Imagine Alice (the browser) and Bob (the server) want to agree on a secret key without Eve (an eavesdropper) discovering it:

1. Alice and Bob publicly agree on a generator base $g$ and a large prime modulus $p$. Eve sees both $g$ and $p$.
2. Alice picks a random private secret number $a$. She computes her public key: \(A = g^a \pmod p\) Alice sends $A$ across the wire to Bob.
3. Bob picks a random private secret number $b$. He computes his public key: \(B = g^b \pmod p\) Bob sends $B$ across the wire to Alice.
4. Now, both parties compute the shared secret $S$:
   • Alice calculates: $S = B^a \pmod p = (g^b)^a = g^{ab} \pmod p$
   • Bob calculates: $S = A^b \pmod p = (g^a)^b = g^{ab} \pmod p$

What about Eve? Eve intercepted $g, p, A = g^a$, and $B = g^b$. To compute $S$, she must deduce $a$ or $b$. But computing $a = \log_g(A) \pmod p$ is the Discrete Logarithm Problem—a computational challenge that would take the world’s most powerful supercomputers billions of years to crack when $p$ is sufficiently large!

 Alice (Browser)                     Insecure Wire                      Bob (Server)
 [Secret: a]                       [Public: g, p]                     [Secret: b]
      |                                   |                                |
      |-------- Send Public A (g^a) ----->|------------------------------->|
      |<------- Send Public B (g^b) ------|<-------------------------------|
      |                                   |                                |
  Compute:                            Eve sees:                        Compute:
  S = B^a = g^(ab)                   (g, p, A, B)                      S = A^b = g^(ab)
  [Shared Secret S]                 [Cannot find S!]                   [Shared Secret S]

2. The Evolution: TLS 1.2 vs TLS 1.3

Prior to 2018, the internet ran on TLS 1.2 (defined in RFC 5246). TLS 1.2 was robust, but it suffered from two key drawbacks: high connection latency (2 full round trips before sending application data) and backwards-compatible support for obsolete, dangerous ciphers (such as static RSA key exchange and RC4).

In 2018, the IETF ratified TLS 1.3 (RFC 8446). It fundamentally revamped the handshake architecture:

       TLS 1.2 Handshake (2-RTT)                         TLS 1.3 Handshake (1-RTT)
   Client                      Server               Client                      Server
     |                            |                   |                            |
     |--------- ClientHello ----->|                   |-- ClientHello + KeyShare ->|
     |                            |                   |   (e.g., Curve25519 g^a)   |
     |<-------- ServerHello ------|                   |<-- ServerHello + KeyShare -|
     |<-------- Certificate ------|                   |    (g^b) + EncryptedExts   |
     |<---- ServerKeyExchange ----|                   |    + Cert + Finished       |
     |<----- ServerHelloDone -----|                   |                            |
     |                            |                   |=== HTTP App Data (GET) ===>|
     |---- ClientKeyExchange ---->|                   |<== HTTP App Data (Resp) ===|
     |---- [ChangeCipherSpec] --->|
     |--------- Finished -------->|
     |                            |
     |<--- [ChangeCipherSpec] ----|
     |<-------- Finished ---------|
     |                            |
     |=== HTTP App Data (GET) ===>|
     |<== HTTP App Data (Resp) ===|

Notice the crucial difference: in TLS 1.3, the client speculatively assumes the server supports popular elliptic curves (like Curve25519 or secp256r1) and bundles its key share $g^a$ directly inside the ClientHello. The server answers with its key share $g^b$, immediately derives the symmetric key, and encrypts its certificate and Finished message in the very same response packet!

3. Why Perfect Forward Secrecy Matters

Imagine an intelligence agency or malicious actor recording petabytes of encrypted internet traffic passing through submarine fiber cables today.

Under the old static RSA key exchange (prevalent in early SSL and TLS versions), if the private RSA key of a bank or government server were stolen, compromised, or subpoenaed five years later, the attacker could retroactively decrypt every single past historical session ever recorded from that server!

With ECDHE (Ephemeral Diffie-Hellman):

1. The private keys $a$ and $b$ are generated purely in RAM for that single connection.
2. Once the symmetric session key is derived, $a$ and $b$ are erased from memory with zeroing instructions.
3. Even if the server hardware is physically confiscated by an adversary in the future, past communications remain mathematically impervious to decryption.

This is why TLS 1.3 completely eradicated static RSA key exchange, mandating ephemeral Diffie-Hellman by law of the protocol.