HTTP vs HTTPS: The Security Story Every Internet User Should Know

You've seen the padlock icon in your browser's address bar. You've probably noticed that some websites have "https" and some just have "http" at the start of their address. You've maybe seen browsers warn you about "Not Secure" sites. But do you actually know what any of it means? Do you know what's happening to your data when a site is secure versus when it isn't?

This is genuinely important knowledge for anyone using the internet — which is everyone. Let's get into it.

HTTP: The Original Protocol, and Its Problem

HTTP stands for HyperText Transfer Protocol. It was created by Tim Berners-Lee in 1989 as part of his invention of the World Wide Web, and it's the protocol that defines how web browsers request pages from web servers and how those servers send the pages back.

HTTP is a plain text protocol. That means when your browser sends an HTTP request, it sends it as human-readable text. If you could intercept that request in transit, you could read it easily. Every header, every piece of data — all of it is right there in the open.

This was fine in the early days of the web, when the internet was small, largely academic, and not used for anything sensitive. But as commerce, banking, healthcare, and private communication moved online, sending data in plain text became a serious problem.

Here's the threat: imagine you're at a coffee shop, connected to the public WiFi. If you visit an HTTP website and enter your username and password, anyone on that same WiFi network with a packet-sniffing tool (and basic technical knowledge) could intercept your traffic and read your credentials. This is called a man-in-the-middle attack, and it's shockingly easy to pull off on unencrypted networks.

The internet needed encryption. That's where HTTPS came in.

HTTPS: HTTP with a Security Layer

HTTPS stands for HTTP Secure. It's the same HTTP protocol, but it adds an encryption layer called TLS (Transport Layer Security) — formerly known as SSL (Secure Sockets Layer), a name you still hear used informally even though SSL is technically deprecated.

When you visit an HTTPS website, your browser and the server perform what's called a TLS handshake before any HTTP data is exchanged. This handshake accomplishes three things:

1. Authentication: Your browser verifies that the server really is who it claims to be. This is done using a digital certificate issued by a trusted third party called a Certificate Authority (CA).

2. Key Exchange: The browser and server securely negotiate a shared encryption key that will be used to encrypt all subsequent communication. This is done using clever mathematics that ensures even if someone is watching the handshake in real time, they can't figure out the key.

3. Encryption: All HTTP data sent after the handshake is encrypted with that shared key. Anyone intercepting the traffic sees only an unreadable stream of random-looking data.

TLS Certificates and Certificate Authorities

The authentication step is one of the most interesting and complex parts of HTTPS. Let me explain how it works.

When you connect to `www.yourbank.com`, your browser needs to be sure it's really talking to your bank's server and not some attacker's server pretending to be your bank. This is verified through a digital certificate.

A certificate is a file that the server sends to your browser during the TLS handshake. It contains:

A Certificate Authority is an organization that verifies identities and signs certificates. Browser makers like Google, Mozilla, and Apple maintain a list of CAs they trust (called the root store). If a server presents a certificate signed by a trusted CA, the browser trusts it. If the certificate is self-signed or signed by an untrusted CA, the browser shows a security warning.

Major CAs include DigiCert, Comodo, and GlobalSign. There's also Let's Encrypt, a free, automated CA launched in 2016 that massively accelerated the adoption of HTTPS by making certificates free and easy to obtain for anyone.

How Encryption Actually Works: Public and Private Keys

Here's the really elegant part of HTTPS, and it requires just a moment of patience to understand properly.

HTTPS uses a type of encryption called asymmetric encryption (also called public-key cryptography) during the initial handshake. This is how it works:

Every server has two mathematically linked keys: a public key and a private key. These are just very large numbers. Anything encrypted with the public key can only be decrypted with the private key, and vice versa. The public key is shared with everyone (it's in the certificate). The private key never leaves the server — it's a closely guarded secret.

During the TLS handshake, the browser uses the server's public key to securely send a piece of secret information (called the "pre-master secret") to the server. Because this information is encrypted with the server's public key, only the server can decrypt it (using its private key). Both sides then use this secret to independently compute the same symmetric session key, which is then used to encrypt all subsequent HTTP communication.

The reason we switch from asymmetric to symmetric encryption at this point is performance. Asymmetric encryption is mathematically complex and slow. Symmetric encryption is fast. The handshake uses asymmetric encryption to securely establish a shared key, and then switches to fast symmetric encryption for the actual data.

What Does the Padlock Icon Actually Mean?

The padlock icon in your browser address bar means that the connection between your browser and the server is encrypted. Specifically, it means:

What the padlock icon does not mean:

This is a critical distinction that many people miss. Scammers and phishing sites can get free TLS certificates too — the padlock only means the connection is encrypted, not that you're talking to a legitimate organization. A phishing site can have a padlock.

For high-assurance verification, you need what's called an EV (Extended Validation) certificate, which requires the CA to verify the legal identity of the organization. Browsers used to show the company name in green in the address bar for EV certificates, though many browsers have moved away from showing this prominently.

HTTPS in Practice: What It Protects (and What It Doesn't)

HTTPS protects data in transit — between your browser and the server. This is very valuable. On a public WiFi network, HTTPS means an attacker watching the traffic can't read your credentials, your banking details, or your private messages to a website.

But HTTPS does not protect data at rest — once it arrives at the server. If a company's database is breached, your data can still be exposed even if it was transmitted securely. HTTPS is one piece of the security puzzle, not the whole thing.

HTTPS also doesn't hide the fact that you visited a particular website. Because DNS lookups typically happen before the TLS connection is established, your ISP (and anyone watching at the network level) can often still see what domains you're visiting, even if they can't see what pages you visited or what you typed. Technologies like DNS over HTTPS and encrypted SNI (Server Name Indication) address this, but adoption is still incomplete.

The Transition to HTTPS: Where We Are Today

For most of the early web's history, HTTPS was used only for login pages and payment forms — the parts where sensitive data was clearly at stake. The rest of the web was unencrypted HTTP.

That changed dramatically over the 2010s. Several factors drove the shift:

Let's Encrypt (2016): Made free, automated certificates available to everyone. No more excuses about cost.

Google's SEO signal (2014): Google announced that HTTPS sites would get a small ranking boost in search results. Webmasters noticed.

Browser warnings: Chrome and Firefox began marking HTTP sites as "Not Secure" in the address bar. Users started noticing and complaining about visiting insecure sites.

The result? As of 2024, well over 95% of web traffic is encrypted with HTTPS. HTTP-only websites have become genuinely rare. The web got dramatically more private and secure in the space of about a decade.

TLS Versions: Why Updates Matter

TLS itself has evolved over the years:

When you see a website failing to load with a security error, one common cause is that the server is running an outdated TLS version that your browser no longer accepts. This is actually a security feature working correctly.

Practical Takeaways

Here's what you should actually do with this knowledge:

Always check for HTTPS before entering sensitive information on any website — login credentials, payment details, personal information. The padlock should be there.

Be aware that a padlock doesn't mean a site is legitimate — phishing sites can have HTTPS too. Check the domain name carefully.

Avoid using public WiFi without a VPN for sensitive activities. Even with HTTPS, VPNs add another layer of protection.

If you run a website, make sure it's using HTTPS. With Let's Encrypt and most hosting providers supporting automatic certificate management, there's truly no excuse in 2024.

The story of HTTPS is one of the most successful security improvements in the history of the internet. In about a decade, the web went from mostly unencrypted to almost entirely encrypted. That's genuinely rare good news in the world of cybersecurity. Enjoy it.