Every time you shop online, log into your bank, or even check your email, you rely on a technology called HTTPS to keep your information safe.
It’s so common today that most browsers show a little padlock icon in the address bar to let you know your connection is secure.
But what actually happens behind the scenes when you type in a website address that starts with HTTPS?
Here’s the whole process:
Let’s break it down step by step.
Step 1: Establishing a Basic Connection (TCP Handshake)
Before any secure communication can happen, your browser (the client) and the website’s server need to set up a basic connection. This is done using something called a TCP handshake.
Think of this like two people agreeing on a phone line before they start talking. At this point, the connection is open but the conversation isn’t yet private—if anyone is listening in, they can still see the data.
That’s why HTTPS takes it a step further with encryption.
Step 2: Proving Identity (Certificate Check)
Once the basic connection is ready, your browser wants to make sure it’s really talking to the website it thinks it is. This is where the TLS handshake (Transport Layer Security) begins.
Your browser sends a “hello” message, listing the encryption methods it supports. The server responds by:
Choosing one encryption method (also called a cipher suite).
Sending back a digital certificate.
This certificate contains the server’s public key and is issued by a Certificate Authority (CA)—a trusted third party. Your browser checks this certificate against its built-in list of trusted authorities. If it matches and hasn’t expired or been tampered with, the identity of the website is verified.
If the certificate isn’t valid, you’ll see a warning like “Your connection is not private.”
Step 3: Exchanging Keys Securely (Key Exchange)
Now that your browser trusts the server, the next question is: How do we exchange a secret key safely over the internet, where anyone could be eavesdropping?
Here’s how it works:
Your browser uses the server’s public key (from the certificate) to encrypt a randomly generated session key.
This encrypted session key is sent to the server.
Only the server, which holds the matching private key, can decrypt it.
At this point, both sides share the same session key, but no one else can read it—even if they intercepted the exchange.
This step uses asymmetric encryption (public/private keys) to safely establish the shared session key.
Step 4: Secure Data Transmission
Once the session key is in place, both browser and server switch to symmetric encryption, which is faster and better suited for ongoing communication.
In symmetric encryption, the same key is used for both encrypting and decrypting data. This means:
When you type your credit card number into a form, your browser encrypts it with the session key.
The server uses the same session key to decrypt it and process your payment.
From this point forward, every message between client and server is encrypted, tamper-proof, and private. Even if someone intercepts the traffic, all they’ll see is gibberish.
Why HTTPS Matters
Without HTTPS, data travels over the internet in plain text, making it vulnerable to:
Eavesdropping: Hackers can intercept sensitive information like passwords or card details.
Man-in-the-middle attacks: Someone could alter the communication between you and the website.
Phishing and impersonation: Fake websites could trick users into giving away private data.
With HTTPS:
Your data is encrypted.
The server’s identity is verified.
Communication remains confidential and intact.
This is why modern browsers often block or flag websites that don’t use HTTPS.
Putting It All Together
Here’s the simplified flow of what happens when you visit a secure website:
TCP handshake sets up a basic connection.
TLS handshake begins: your browser checks the website’s digital certificate.
Key exchange ensures both sides share a private session key safely.
Data transmission starts: all further communication is encrypted with the shared session key.
In just a fraction of a second, this entire process unfolds, making sure your communication is both secure and trustworthy.
So, what else will you add to better understand HTTPS?
Here are some interesting articles that I read this week:
Claude Code AI best practices by
A Critical Guide to Content Delivery Networks by
Monolith vs Microservices: The $1M ML Design Decision by
That’s it for today!
Enjoyed this issue of the newsletter?
Share with your friends and colleagues.