How HTTPS Authenticates Websites Using SSL/TLS 🔐
Every time you open a website like Google, Amazon, or your banking portal, your browser shows a small lock icon beside the URL.
But have you ever wondered:
How does the browser actually know the website is genuine?
How does it verify that nobody is impersonating the server or intercepting your data?
This is where HTTPS and the SSL/TLS protocol come in.
In this blog, we’ll break down:
- How HTTPS works
- How SSL/TLS authenticates websites
- What certificates actually do
- How browsers establish secure communication
Let’s dive in.
What is HTTPS(port-443)?
HTTPS stands for:
HyperText Transfer Protocol Secure
It is the secure version of HTTP(port-80).
HTTPS uses SSL/TLS to provide:
Authentication
Encryption
Data Integrity
Without HTTPS, attackers could perform:
- Data Tampering
- Session Hijacking
- MITM: Man-in-the-middle Attack
- SSL Stripping Attack
The Main Goal: Authentication
Before your browser sends any sensitive information, it first needs to answer:
“Am I really talking to the actual website?”
For example:
- Is this really
amazon.com? - Or is it an attacker pretending to be Amazon?
TLS solves this using digital certificates.
The HTTPS Authentication Flow
Let’s understand the process step by step.
Suppose you open:
https://amazon.com
Here’s what happens behind the scenes.
Step 1: Browser Sends "Client Hello"
Your browser initiates communication by sending:
Client Hello
This message contains:
- Supported TLS versions
- Supported cipher suites
- Encryption algorithms
- A random value
The browser is basically saying:
Hey server,
here are the security methods I support.
Step 2: Server Responds with Certificate
The server replies with:
Server Hello
Along with:
- Chosen encryption method
- TLS certificate
- Public key
- Another random number
The most important thing here is the:
TLS Certificate
Think of it like a digital identity card for the website.
It contains:
- Domain name
- Public key
- Expiry date
- Certificate Authority (CA)
- Digital signature
Example:
Domain: amazon.com
Issued By: DigiCert
Step 3: Browser Verifies the Certificate
This is the actual authentication phase.
The browser performs several checks.
1. Domain Verification
The browser checks:
Does the certificate belong to the website I requested?
If you visit:
amazon.com
But the certificate says:
google.com
The browser blocks the connection immediately.
2. Certificate Expiry Check
Certificates have validity periods.
If the certificate is expired, browsers show warnings like:
Your connection is not private
3. Certificate Authority Verification
Browsers already trust certain organizations called:
Certificate Authorities (CAs)
Examples include:
- DigiCert
- Let’s Encrypt
- GlobalSign
These authorities verify website ownership before issuing certificates.
The browser verifies:
- whether the CA is trusted
- whether the CA’s digital signature is valid
If valid:
The website identity is trusted.
How Digital Signatures Work
Certificate Authorities use asymmetric cryptography.
The CA:
- Creates a hash of the certificate
- Encrypts the hash using its private key
Your browser:
- Decrypts the signature using the CA’s public key
- Compares the hashes
If the hashes match:
- the certificate is authentic
- the certificate was not modified
This proves the website is genuine.
Step 4: Secure Key Exchange
Once the website is authenticated, the browser and server establish a shared secret key.
Modern TLS commonly uses:
- Diffie-Hellman
- ECDHE (Elliptic Curve Diffie-Hellman)
This generates a temporary session key.
Why TLS Uses Symmetric Encryption Afterwards
Asymmetric encryption is secure but computationally expensive.
So TLS uses:
| Purpose | Encryption Type |
|---|---|
| Authentication | Asymmetric Encryption |
| Data Transfer | Symmetric Encryption |
This makes HTTPS secure and efficient.
Step 5: Encrypted Communication Begins
Now both sides share the same session key.
All communication becomes encrypted:
- Passwords
- API requests
- Cookies
- Payment data
- User sessions
Even if attackers capture the traffic, they only see encrypted gibberish.
How HTTPS Prevents MITM Attacks
Suppose an attacker tries to intercept traffic and impersonate Amazon.
To succeed, they would need:
- Amazon’s valid certificate
- A trusted CA signature
- Amazon’s private key
Since they don’t possess these:
- browsers detect fake certificates
- the connection gets blocked
This prevents:
Man-in-the-Middle (MITM) attacks
SSL vs TLS
You often hear both SSL and TLS.
Here’s the difference:
| SSL | TLS |
|---|---|
| Older | Modern |
| Insecure | Secure |
| Deprecated | Currently used |
Today, HTTPS mainly uses:
- TLS 1.2
- TLS 1.3
People still casually say “SSL certificate,” even though modern systems use TLS.
What Does the Lock Icon Actually Mean?
That small lock icon means:
The connection is encrypted
The certificate is valid
The website identity is verified
It does not guarantee the website itself is safe or trustworthy.
It only means:
You are securely connected to the real server.
Final Thoughts
Whenever you open a secure website, your browser performs an entire chain of trust verification within milliseconds.
HTTPS authentication relies on:
- Digital certificates
- Certificate Authorities
- Public key cryptography
- Digital signatures
- TLS handshakes
That tiny lock icon represents a massive amount of security happening silently in the background.
Quick Summary
HTTPS authenticates websites by:
- Sending a TLS certificate
- Verifying the certificate
- Validating CA signatures
- Establishing secure session keys
- Encrypting all communication
This ensures:
- Authentication
- Confidentiality
- Integrity
And that’s how HTTPS secures communication on the internet 🔐
Top comments (0)