Every time you open a page, your browser and a server hold a brief conversation: you ask for something, it responds. That dialogue is HTTP, and it's so routine that we rarely think about it. But there's one question that decides almost everything else: does that conversation travel protected, or can anyone along the way read it? The answer separates HTTP from HTTPS, and explains why the browser padlock says less —and more— than you think.
What HTTP is
Before talking about the padlock, you have to understand what it is that gets protected. And what gets protected is HTTP: the language browser and server use to understand each other.
HTTP (HyperText Transfer Protocol) is the web's request-and-response protocol: the client —your browser— asks for a resource and the server responds with it. It's a text protocol and a stateless one: each request is independent, the server doesn't remember the previous one on its own.
An HTTP request is made of a method (GET, POST…), a path (which resource you're asking for), some headers (metadata like the browser, the language or the cookies) and, sometimes, a body (the content you send).
How a request travels
Before HTTP says a single word, you have to reach the server and open a channel to talk over. These are the steps of a normal HTTP request:
- The browser resolves the domain to an IP via DNS: it translates
example.cominto a numeric address to connect to. - It opens a TCP connection to the server. In HTTP, by default, on port 80.
- It sends the request: the method plus the path, followed by the headers (and, if applicable, the body).
- The server returns a response: a status code (200, 404, 500…), its headers and the requested content.
So far everything works. The problem isn't that the request doesn't arrive: it's that in plain HTTP it travels in plain sight across every leg of the network.
The problem: HTTP travels in the clear
In plain HTTP there's no encryption at any point. That means everything that makes up the conversation is readable to any intermediary on the path: the coffee-shop Wi-Fi, your internet provider, every router the packets pass through.
- The full URL —including the path and its parameters—.
- The headers, with client and session data.
- The session cookies, which are the keys to your logged-in session.
- The content of the request and the response, as-is.
And it's not just about reading. A well-placed attacker doesn't only see the traffic: they can modify the response before it reaches you —inject content, alter a link, change what you see—. In HTTP there's nothing to stop them and no way for you to notice.
"If I don't type anything sensitive, HTTP is fine for me." Even if you only read, your session cookies travel with every request: whoever reads them can impersonate you without your password. And over an HTTP page no one guarantees that what you see is what the server sent.
What HTTPS adds
HTTPS is not a new protocol that replaces HTTP. It's the same HTTP, but transported inside a layer that protects it: TLS. The equation is literal: HTTPS = HTTP + TLS. And the default port is no longer 80, it's 443.
TLS gives HTTP three guarantees that didn't exist in the clear:
Confidentiality: it encrypts the traffic, so an intermediary sees unintelligible data instead of your URL, your cookies and your content. Integrity: it detects whether anyone altered the data along the way, so silent tampering is no longer possible. Server authentication: it verifies —via its certificate— that you're talking to who it claims to be, and not an impostor in the middle.
The TLS handshake, simply
Before exchanging a single HTTP request, client and server perform a handshake: an initial greeting that establishes the encrypted channel. Without getting into the detail of cryptographic suites, the idea is this:
- The browser says hello and proposes the connection parameters (the versions and algorithms it supports).
- The server presents its certificate: its identity plus its public key, vouched for by an authority the browser trusts.
- The browser validates that certificate and, from it, both agree on a session key that only they know.
- From that point on, all the HTTP travels encrypted with that key. The same conversation as before, now unreadable from the outside.
The detail of why symmetric and asymmetric keys are combined, and of how a certificate gets your browser to trust a server, is covered in other Fundamentals entries. Here the idea is enough: the handshake verifies identity and agrees on a key; afterward, HTTP speaks encrypted.
What the padlock protects and what it doesn't
When the handshake finishes well, the browser draws the padlock. And this is where almost everyone reads too much into it. The padlock says something very specific —and only that—.
"It has a padlock, so it's a trustworthy site / a legitimate company." No. The padlock does not mean that. It only indicates that the connection is encrypted and that the certificate matches the domain you're visiting. A phishing site can have HTTPS and a flawless padlock: the padlock protects the channel, it doesn't guarantee the intent of whoever is on the other side.
Put another way: the padlock assures you that no one on the path is reading or altering your conversation with that domain. It doesn't tell you whether that domain deserves your trust. Confidentiality and the channel's identity are one thing; the recipient's reputation is a very different one.
HTTP and HTTPS, side by side
| Feature | HTTP | HTTPS |
|---|---|---|
| Default port | 80 | 443 |
| Encryption in transit | No | Yes |
| Integrity | No | Yes |
| Server authentication | No | Yes, via certificate |
| What an intermediary sees | Everything: URL, headers, content | Only the domain and the approximate size |
The banking angle
In banking the question "HTTP or HTTPS?" isn't even raised: everything goes over HTTPS, with no exceptions. But demanding HTTPS isn't enough if a crack is left through which plain HTTP can slip in. That's why two specific flanks are closed off:
- HTTPS is forced with HSTS. HSTS (HTTP Strict Transport Security) is a header that tells the browser: "for this domain, connect only over HTTPS, never over HTTP". This prevents the downgrade to HTTP and the interception attacks that depend on that first unencrypted connection.
- Mixed content is avoided. Mixed content is loading resources over HTTP (an image, a script) inside a page served over HTTPS. A single resource in the clear is enough to open a crack in a page believed to be encrypted, so in banking it's simply not allowed.
HTTP and HTTPS answer the same question —how to request and deliver the web— but only one answers the one that truly matters in a bank: who can read or alter what travels. HTTPS locks down the transport. What it doesn't do —nor does the padlock— is judge for you who you trust. That decision is still yours.
