Deep Dive - HTTPS and TLS

This post will deconstruct the black box of HTTPS. We will move beyond “Public vs Private Keys” and look at how the internet actually keeps secrets.

You type google.com into your browser and a little padlock appears. You take it for granted.

But stop and think about the physics of that moment.

Your request traveled through a Wi-Fi router in a coffee shop through an ISP switch and across a transoceanic fiber cable. At every single hop a bad actor could have been listening.

Yet somehow you and the Google server agreed on a secret code that no one else knows without ever meeting in person.

This is the miracle of TLS (Transport Layer Security).

For web engineers TLS is often just a configuration headache or an expired certificate that brings down production. But under the hood it is a complex interplay of Number Theory and Protocol Handshakes.

This post will deconstruct the black box of HTTPS. We will move beyond “Public vs Private Keys” and look at how the internet actually keeps secrets.

The Impossible Problem of Key Exchange

The core problem of cryptography is simple. I want to send you a message in a locked box. But I have the only key. If I send you the key the spy listening on the wire will copy the key and unlock the box.

How do we share a key without sending the key?

Diffie Hellman Key Exchange

This is the mathematical breakthrough that powers the internet. It allows two parties to generate the same shared secret using only public information.

You can read details on wikipedia.

Imagine we are mixing paint.

1. Public Color - We agree on a starting color Yellow. Everyone sees this.

2. Secret Colors - I pick Red (my secret). You pick Blue (your secret).

3. The Mix - I mix Yellow + Red = Orange. You mix Yellow + Blue = Green.

4. The Exchange I send you my Orange. You send me your Green. The spy sees Orange and Green but cannot unmix them to find our secrets.

5. The Final Magic I take your Green and add my secret Red. You take my Orange and add your secret Blue.

6. The Result We both end up with the same final brown color (Yellow + Red + Blue). The spy cannot recreate this.

In the real world we do not use paint. We use Elliptic Curves (ECDHE). The “mixing” is point multiplication on a curve which is easy to do one way but mathematically impossible to reverse (the Discrete Logarithm Problem). This allows the client and server to derive a Session Key without ever transmitting it.

The Identity Problem (Certificates)

Encryption is useless if you are talking to the wrong person. If I encrypt my credit card but send it to a hacker’s server I am still in trouble

I need to know that google.com is actually Google. This is the job of the Certificate.

The Chain of Trust

The internet relies on a feudal system of trust known as PKI (Public Key Infrastructure).

1. The Root CA - Your operating system (Windows macOS iOS) comes pre installed with a list of trusted entities called Root Certificate Authorities (like DigiCert or Let’s Encrypt). You trust them because Apple or Microsoft tells you to.

2. The Intermediate CA - The Root CA keeps its private key offline in a vault. It uses it to sign a certificate for an Intermediate CA which does the daily work.

3. The Leaf Certificate - The Intermediate CA signs the certificate for google.com.

When your browser visits Google it asks for the certificate. It checks the Digital Signature. It calculates the hash of the certificate and decrypts the signature using the Intermediate CA’s public key. If they match it knows the Intermediate CA definitely signed it. It repeats this up the chain to the Root.

The Handshake (TLS 1.2 vs 1.3)

We discussed the RTT (Round Trip Time) cost of handshakes in our Networking Deep Dive. The evolution of TLS has been a war against latency.

Understanding the Cipher Suite

When the client connects it sends a list of languages it speaks. You have likely seen a string like this TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.

This is not random. It is a menu

• Protocol - TLS

• Key Exchange - ECDHE (Elliptic Curve Diffie Hellman Ephemeral)

• Authentication - RSA (The type of Certificate signature)

• Encryption - AES_256_GCM (The Symmetric Algorithm used for data)

• Integrity - SHA384 (The Hashing algorithm used to verify packets)

TLS 1.3 The Fast Lane (1 RTT)

TLS 1.3 dropped support for old insecure algorithms and introduced 0-RTT (Zero Round Trip) resumption.

The client no longer asks “What language do you speak?” It says “I assume you speak Elliptic Curve 25519 so here is my key share right now.”

The result, the connection is established in a single round trip.

Perfect Forward Secrecy (PFS)

In the old days (RSA Key Exchange) if a hacker recorded your encrypted traffic for 5 years and then stole the server’s Private Key they could decrypt everything from the past 5 years.

Modern TLS uses Ephemeral key exchanges (the ‘E’ in ECDHE).

For every single connection the server generates a brand new “Paint Mixing” secret pair just for that session.

The result, once the session is over the server deletes the ephemeral key. Even if the FBI or a hacker steals the server’s main Signing Key tomorrow they cannot decrypt the traffic from yesterday because the session keys are already gone.

Asymmetric vs Symmetric Encryption

A common interview question is “Does HTTPS use Asymmetric or Symmetric encryption?”

The answer is Both.

Asymmetric (Public Private Key)

This is slow and computationally expensive. We only use this during the Handshake to prove identity (RSA/ECDSA) and establish the shared secret.

Symmetric (AEAD)

Once we have the shared key we switch to Authenticated Encryption with Associated Data (AEAD) like AES-GCM.

• Encryption - Scrambles the data so it cannot be read.

• Authentication (The Tag) - Ensures the data has not been tampered with. If a bit is flipped in transit the decryption fails instantly. This prevents active “Man in the Middle” attacks from modifying your HTML.

The Chicken and Egg Problem (SNI)

In the early days of the web one server IP address could only host one HTTPS certificate.

This was because of a logical paradox.

1. The client connects to the IP 1.2.3.4.

2. The Client sends the “Client Hello.”

3. The Server must reply with a Certificate.

The server hosts example.com and blog.net on the same IP. Which certificate should it send? It does not know which site the user wants because the Host header is inside the HTTP request which comes after the encryption is set up.

Server Name Indication (SNI) solved this.

SNI extends the “Client Hello” message to allow the client to say “I am trying to reach example.com“ in plain text before the encryption starts.

This allows the Load Balancer to pick the correct certificate to complete the handshake. Without SNI modern cloud hosting and CDNs would be impossible.

---

Conclusion

It is Just Math.

HTTPS feels like magic but it is really just a stack of three mathematical concepts.

1. Diffie Hellman - lets us share secrets in public.

2. PKI (Signatures) - lets us trust identity via a chain of signatures.

3. Symmetric Encryption (AEAD) - lets us transfer data quickly and verify its integrity.

As an engineer you do not need to implement AES yourself but you do need to understand that every secure connection costs round trips and CPU cycles. Optimizing your TLS version and certificate chain is just as important as optimizing your database queries.

---