What Happens When You Type https://

You type https://yourbank.com into your browser and hit Enter. A second later, the page loads. It feels instant. But a lot happened in that one second. Let’s trace the full journey.

Step 1: DNS Lookup

Your browser needs to find the IP address of yourbank.com. It asks a DNS server: “What’s the IP address for yourbank.com?” The DNS server responds with something like 93.184.216.34.

This step happens in plain text. Anyone watching can see which domain you’re looking up. (There are efforts to encrypt DNS too, like DNS over HTTPS, but that’s a separate topic.)

Step 2: TCP Connection

Your browser opens a TCP connection to 93.184.216.34 on port 443 (the standard port for HTTPS). This is the classic three-way handshake: SYN, SYN-ACK, ACK.

At this point, you have a reliable connection to the server. But it’s not secure yet. Data sent over this TCP connection would be in plain text.

Step 3: The TLS Handshake

This is where the magic happens. Before any HTTP data is exchanged, the browser and server perform a TLS handshake. During this handshake, three things happen:

The server proves its identity (authentication)
Both sides agree on encryption keys (key exchange)
They establish the encryption parameters for the session

The handshake takes one or two round trips depending on the TLS version. We’ll dive deep into the handshake in later chapters. For now, just know that after the handshake completes, both sides have a shared secret key that no one else knows.

Step 4: Encrypted HTTP

Now the browser sends the actual HTTP request (GET /index.html), but encrypted with the shared key. The server decrypts it, processes it, encrypts the response, and sends it back. The browser decrypts the response and renders the page.

Every piece of data from this point forward is encrypted. The URLs you visit on the site, the forms you submit, the cookies, all of it.

The Full Picture

sequenceDiagram
    participant B as Browser
    participant D as DNS Server
    participant S as Bank Server

    Note over B,D: Step 1: DNS (plain text)
    B->>D: What's the IP for yourbank.com?
    D->>B: 93.184.216.34

    Note over B,S: Step 2: TCP (plain text)
    B->>S: SYN
    S->>B: SYN-ACK
    B->>S: ACK

    Note over B,S: Step 3: TLS Handshake
    B->>S: ClientHello (I support these ciphers...)
    S->>B: ServerHello + Certificate + Key Share
    B->>S: Key Share + Finished
    S->>B: Finished

    Note over B,S: Step 4: Encrypted HTTP
    B->>S: GET /account (encrypted)
    S->>B: 200 OK + page content (encrypted)

Where TLS Sits

TLS sits between TCP and HTTP. It’s a layer in the middle.

graph TB
    A[HTTP - your web requests] --> B[TLS - encryption layer]
    B --> C[TCP - reliable delivery]
    C --> D[IP - routing across the internet]

HTTP doesn’t know or care about encryption. It just sends requests and gets responses. TCP doesn’t know or care about encryption either. It just delivers bytes reliably. TLS sits between them, encrypting everything HTTP sends before handing it to TCP, and decrypting everything TCP delivers before handing it to HTTP.

This layered design is elegant. HTTP didn’t need to change to become secure. TCP didn’t need to change. A new layer was inserted between them, and suddenly everything was encrypted.

The Padlock Icon

That padlock icon in your browser’s address bar means: a TLS handshake completed successfully, the server presented a valid certificate, and all data is being encrypted.

It does not mean the website is safe or trustworthy. A phishing site can have a padlock too. The padlock means the connection is encrypted and the server proved it owns the domain. It says nothing about whether the people behind the domain are honest.

What an Eavesdropper Sees

If someone is capturing your traffic (the person at the coffee shop, your ISP, a compromised router), here’s what they can see after TLS is in place:

The DNS lookup (which domain you’re visiting), unless you use encrypted DNS
The IP address you’re connecting to
The fact that a TLS handshake happened
The SNI field in the ClientHello (which hostname you requested), though this is being encrypted in newer standards
The size and timing of encrypted packets

What they cannot see:

The actual URLs you visit on the site
Any data you submit (passwords, credit cards, forms)
The content of the pages you view
Cookies or session tokens

The encrypted data is just gibberish without the session key. And the session key was never sent over the wire. It was derived through the handshake in a way that only the browser and server can compute it.

The Big Questions

Now you have the big picture. But it raises a lot of questions:

How does the server “prove its identity”? What stops an attacker from pretending to be your bank?
How do both sides agree on a secret key without ever sending the key over the wire?
What encryption algorithms are used, and who decides?
What happens if something goes wrong during the handshake?
How do load balancers and CDNs fit into this picture?

Each of these questions has a precise answer, and each answer builds on the previous one. Let’s start with the three fundamental problems that TLS solves.

Next: The Three Promises

← Previous Chapter Next Chapter →