HTTP vs HTTPS

If you've worked with web apps even a little, you’ve likely seen http:// and https:// URLs all over the place. You might already know that the “S” in HTTPS stands for secure, but what does that actually mean?

In this post, let's take a peek under the hood. We'll break down the handshake process in both HTTP and HTTPS — and more importantly, understand what changes and why it matters.

First, Let’s Talk HTTP

What actually happens when you open a URL like http://example.com?

Here’s what goes on, step by step:

1. Your browser establishes a TCP connection with the server:
   • It sends a SYN (synchronize) message
   • The server replies with SYN-ACK
   • Your browser acknowledges with ACK

This is the standard TCP 3-way handshake, used for all reliable network connections.

2. Then, your browser sends the actual HTTP request

GET / HTTP/1.1
Host: example.com

3. The server responds with

HTTP/1.1 200 OK
Content-Type: text/html
[HTML Content...]

That’s it. Super simple.

But there's a problem: It’s all in plain text.

Anyone sitting between you and the server (think: ISPs, public Wi-Fi snoopers, malicious proxies) can see and modify everything. Your URLs, cookies, form data — all exposed.

Enter HTTPS – The Secure Layer

Now let’s see what happens when you go to https://example.com.

Yes, the "S" means "Secure", but the real magic comes from what’s called a TLS handshake (previously SSL).

So now the handshake is:

TCP Handshake ⟶ TLS Handshake ⟶ Encrypted HTTP

Let’s break down the TLS handshake, and I’ll explain two versions — TLS 1.2 (still widely used) and the newer TLS 1.3 (which is faster and simpler).

In both versions of TLS handshake, the idea is to derive a common session key which is known to both the client and the server. And that is then used to encrypt and decrypt the messages by both sender and receiver.

🔐 TLS 1.2 Handshake (the older, more verbose one)

When your browser wants to securely connect to a server:

1. ClientHello
   • Your browser sends a hello with:
     • Supported TLS versions
     • Supported cipher algorithms
     • A random number
     • (Optionally) the domain name (via SNI)
2. ServerHello
   • Server responds with:
     • Chosen TLS version and cipher
     • A random number
     • Its SSL certificate (this proves its identity)
     • Other options like session IDs
3. Certificate Validation
   • Your browser checks the certificate:
     • Is it signed by a known Certificate Authority?
     • Has it expired?
     • Is it for the right domain?
4. Key Exchange
   • Your browser creates a secret key (pre-master secret)
   • It encrypts it using the server’s public key
   • Server decrypts it using its private key
5. Both derive the same session key
   • Now both sides can encrypt/decrypt messages using this symmetric key
6. Finished
   • Encrypted communication begins (your actual HTTP requests start here)

Phew, that’s a lot, right? This handshake takes 2 full round trips before the first byte of your actual web page is sent.

⚡ TLS 1.3 Handshake (the faster, modern one)

TLS 1.3 trims the fat and gets us to encryption faster:

1. ClientHello
   • Same as before, but includes the key share directly
2. ServerHello
   • Sends its own key share + certificate in one go
3. Key is derived
   • Browser and server derive session key immediately
4. Handshake complete
   • HTTP requests start — encrypted from the start

With TLS 1.3, you save one round trip, which adds up big time for global services.

📊 Summary: HTTP vs HTTPS

🧠 What This Means for Developers

• Always default to HTTPS, even for static sites.
• TLS handshakes add latency, but it’s worth it (and TLS 1.3 helps).
• If you're building backend services or APIs, use HTTPS internally too, especially in multi-cloud or hybrid setups.
• You don’t implement TLS by hand — your web server (like Nginx or Apache) or platform (like AWS ALB or Cloudflare) handles it.

🌐 Real World Analogy

HTTP is like shouting your credit card number across a crowded room.
HTTPS is like whispering it in someone’s ear inside a soundproof room.

🧾 Conclusion

HTTPS isn’t just a best practice anymore — it’s a requirement. Modern browsers throw warnings, APIs get blocked, and users get nervous without it.

By understanding how the handshake works, you appreciate why HTTPS exists and how important it is for secure web communication.

Next time someone asks, “What does that little padlock actually do?” — now you know.

Happy Learning!