Analogy
Imagine you're sitting in a coffee shop.
You connect to the free Wi-Fi.
You decide to log into your bank account.
Your browser sends your username and password over the network.
Now imagine every person connected to that same Wi-Fi can read everything you're sending.
Your password.
Your balance.
Your account number.
Terrifying.
Yet that's exactly how the early Internet worked.
There was no encryption.
No certificates.
No secure connections.
Just plain text traveling across the network.
HTTPS was invented to solve this problem.
But here's the fascinating part:
Your browser has never met your bank's server before.
So how do two complete strangers agree on a secret encryption key while an attacker is listening to every message?
Let's find out.
Before HTTPS
HTTP sends everything as plain text.
Imagine requesting a webpage.
GET /login HTTP/1.1
Host: bank.com
username=alice
password=myPassword123
Anyone who intercepts this packet can read it.
Wireshark.
Hackers.
Malicious Wi-Fi hotspots.
ISPs.
Nothing is hidden.
HTTP provides functionality.
It provides zero confidentiality.
Enter HTTPS
HTTPS is simply:
HTTP
+
TLS
Notice something important.
HTTP didn't change.
TLS wraps HTTP in encryption.
Think of TLS as an armored truck carrying ordinary letters.
The letters remain the same.
The transport becomes secure.
What Does HTTPS Actually Protect?
HTTPS provides three major guarantees.
1. Confidentiality
Nobody can read your data.
Even if someone captures every packet...
They see encrypted gibberish.
Instead of:
password=OpenSesame
They see:
8FA91B4D928AC17C3D...
2. Integrity
Imagine a hacker intercepts:
Transfer $100 and changes it to:
Transfer $10,000
TLS detects that the message was modified.
The connection immediately fails.
3. Authentication
How do you know you're actually talking to your bank?
Not a fake server pretending to be it?
This is where certificates enter the picture.
The Biggest Problem
Imagine I want to send you a locked box.
I lock it.
Now...
How do I safely send you the key?
If I send the key with the box...
Anyone can steal both.
This is exactly the problem HTTPS had to solve.
Symmetric Encryption
Symmetric encryption uses one secret key.
Key
↓
Encrypt
↓
Ciphertext
↓
Decrypt
↓
Same Key
Advantages:
Extremely fast
Perfect for large files
Efficient
Problem:
Both sides need the same secret key.
How do they agree on that key?
Asymmetric Encryption
Instead of one key...
There are two.
Public Key
Private Key
Anyone may know the public key.
Nobody should ever know the private key.
Think of it like a mailbox.
Anyone can drop letters inside.
Only the owner can open it.
Why Not Encrypt Everything with RSA?
RSA (or modern alternatives like Elliptic Curve Cryptography) is computationally expensive.
Encrypting an entire Netflix movie with asymmetric encryption would be painfully slow.
Instead HTTPS combines both worlds.
Fast symmetric encryption.
Safe asymmetric key exchange.
The best of both.
Meet TLS
TLS performs a handshake before any HTTP data is exchanged.
This handshake establishes trust.
Generates shared secrets.
Chooses encryption algorithms.
Verifies certificates.
Only after all of this...
Does HTTP begin.
Step 1 — Client Hello
Your browser starts.
Hello!
I support:
AES
ChaCha20
TLS 1.3
Random Number
Think of this as introducing yourself.
Step 2 — Server Hello
The server replies.
Great.
Let's use:
TLS 1.3
AES-256
Here's my certificate.
Now comes the interesting part.
Step 3 — Certificate
The certificate contains information like:
Domain
Public Key
Expiration Date
Certificate Authority
Digital Signature
Notice...
The server isn't saying:
"Trust me."
Instead it's saying:
"Someone you already trust verified me."
Certificate Authorities
Browsers already trust organizations like:
Let's Encrypt
DigiCert
GlobalSign
Sectigo
When a certificate is signed by one of these trusted authorities, the browser can verify that signature.
It's similar to a passport.
You don't personally know the passport holder.
You trust the government that issued it.
What If Someone Creates a Fake Certificate?
Suppose an attacker generates a fake certificate for:
bank.com
The browser checks the digital signature.
It doesn't match any trusted Certificate Authority.
Immediately:
Your connection is not private.
The browser refuses the connection
Key Exchange
Now the browser knows it's talking to the real server.
Both sides perform a key exchange (commonly using Elliptic Curve Diffie–Hellman Ephemeral (ECDHE) in TLS 1.3) to derive the same shared secret.
Here's the remarkable part:
Neither side ever sends the secret encryption key across the network.
They independently calculate the same shared key using exchanged public information and their own private values.
Even if someone captures every packet, they cannot derive the session key.
This is one of the cleverest ideas in modern cryptography.
Session Keys
Once both sides derive the shared secret...
RSA (or more accurately in modern TLS, the key exchange mechanism) has done its job.
From this point onward...
Everything uses symmetric encryption.
Usually:
AES-GCM
ChaCha20-Poly1305
Because they're much faster.
Why HTTPS Is Fast
Many developers assume HTTPS encrypts every message with RSA.
It doesn't.
RSA or ECDHE helps establish the secure session.
After that...
Symmetric encryption handles almost all application data.
This is why HTTPS is nearly as fast as HTTP on modern hardware.
What Happens Every Time You Visit a Website?
The flow looks like this:
Browser
↓
TCP Connection
↓
TLS Handshake
↓
Certificate Verification
↓
Key Exchange
↓
Shared Secret
↓
Encrypted HTTP
↓
Website Loads
Common Myths
"HTTPS encrypts the entire Internet."
No.
It encrypts the communication between your client and the server.
"HTTPS hides which website I'm visiting."
Not entirely.
Your ISP can usually see the destination IP address and some metadata, although modern technologies reduce what is exposed.
"The padlock means the website is safe."
No.
It only means the connection is encrypted and the certificate is valid.
A phishing website can also have HTTPS.
"HTTP is obsolete."
Not completely.
HTTP still exists.
HTTPS is simply HTTP running over TLS.
Real-World Examples
Uses HTTPS:
Online banking
GitHub
Gmail
Amazon
APIs
Payment systems
Without HTTPS:
Passwords
Cookies
Tokens
Credit card numbers
would all travel in plain text.
Interview Questions
a.Why does HTTPS need certificates?
To verify the server's identity and prevent attackers from impersonating legitimate websites.
b.Why use both symmetric and asymmetric encryption?
Asymmetric encryption (or key exchange) solves the problem of establishing trust and securely deriving a shared secret. Symmetric encryption is then used because it's much faster for encrypting the actual data.
c.Why is HTTPS built on TCP?
TLS requires reliable, ordered delivery during the handshake and while exchanging encrypted records. TCP provides those guarantees.
d.Does HTTPS stop hackers?
It protects data in transit between you and the server.
It does not protect against:
Weak passwords
SQL Injection
XSS
Malware on your computer
Social engineering
HTTPS solves one specific problem:
Protecting communication while it's traveling across the network.
Key Takeaways
Every time you visit an HTTPS website, your browser and the server perform a carefully orchestrated dance before a single web page is loaded. They agree on encryption algorithms, verify the server's identity through a trusted certificate, securely derive a shared secret without ever transmitting it, and then switch to fast symmetric encryption for the rest of the session.
The result is that even if someone intercepts every packet traveling across the network, they cannot read or modify the protected data without the session keys.
That small padlock in your browser represents decades of cryptographic research working together to make everyday activities—like online banking, shopping, email, and APIs—secure enough to use over an untrusted Internet.
Top comments (0)