How HTTPS Actually Works: TLS, Certificates, and Encryption

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 and 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, but 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 and 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, 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.