HTTP and HTTPS

HTTP, the Hypertext Transfer Protocol, is what a browser and a server use to exchange web content: pages, images, files, API responses.

HTTPS is the same protocol carried inside a TLS connection, so that what is exchanged is encrypted and the server is authenticated.

Both are fundamental to how the web works, and the difference between them is entirely about what happens to the traffic in between.

HTTP

The standard protocol for transferring data on the web, served conventionally on port 80.

It sends everything in the clear. Anyone positioned between the two ends, on a shared wireless network, on a compromised router, at an intermediate provider, can read what is being sent and can change it without either end noticing.

That is not a flaw in HTTP. It was designed to move documents, and confidentiality was never part of the design.

HTTPS

The same requests and responses, unchanged, carried inside a TLS connection, served conventionally on port 443.

It provides three things, and it is worth naming them separately because they are often collapsed into “encrypted”:

Confidentiality. An observer in the middle sees that a connection exists and roughly how much data moves, not what it contains.

Authentication of the server. The certificate says which name the server is entitled to serve, backed by a public key infrastructure that the client trusts.

Integrity. Content altered in transit is detected and the connection fails, rather than the modified version being delivered silently.

A worked example

Somebody buys from a shop over HTTP. Their card details and password travel in the clear, and anybody on the path can read them.

Over HTTPS the same details travel inside a TLS connection: unreadable to an observer, and delivered to a server that proved which name it holds.

HTTPS is HTTP over TLS, and TLS is more than HTTPS

Two shortcuts are worth undoing.

The first: HTTPS is not a separate protocol. It is HTTP transported inside a TLS connection. What encrypts, what authenticates the server with a certificate and what detects tampering is TLS. HTTP itself does not change at all.

The second is a correction that applies to almost every description of this subject, including older versions of this one: the phrase “SSL/TLS encryption” is out of date. SSL has been obsolete for years. The current name is TLS, the current version is TLS 1.3, versions 1.0 and 1.1 are formally retired, and TLS 1.2 is still the bulk of what is deployed.

TLS is also not only for the web: it protects mail and many other protocols, so saying HTTPS when you mean TLS leaves out half the problem. It is the mechanism behind encryption in transit.

And what a review actually finds is almost never the protocol. It is the version and the configuration: obsolete versions still offered because of one old client nobody wants to break, weak cipher suites left negotiable, certificates expired or poorly validated by the client. A modern server does not help if it keeps a weak path open, and a client that does not validate the certificate can be intercepted no matter how good the server is. Where an application controls both ends, certificate pinning narrows what it will accept.