The HTTPS protocol

HTTP is insecure by design.

When you ask a web server for a page, your data makes two trips: from the browser to the server, and from the server back to the browser. Then the page needs CSS, JavaScript files, images, and each of those is another exchange.

Every network your data crosses on those trips can inspect it and manipulate it.

The consequences can be serious. Your activity can be logged by a third party you don’t even know exists. Some networks inject ads into pages. And you can be the target of a man-in-the-middle attack, where someone sits between you and the server, reads your data, changes it, or impersonates your computer. On a public unencrypted Wi-Fi network, listening to HTTP packets is trivial.

HTTPS solves the problem at the root: the entire communication between your browser and the web server is encrypted.

HTTPS everywhere

A few years ago you could get away with encrypting only the login page or the checkout. SSL certificates were expensive and annoying to set up, so most sites just used HTTP.

Today HTTPS is a requirement on any site. More than half of the Web uses it. Chrome marks plain HTTP sites as insecure, which gives you a good reason to force HTTPS on everything you publish.

The default port is 80 for HTTP and 443 for HTTPS. You don’t need to add it to the URL if the server uses the default.

SSL and TLS

HTTPS is also called HTTP over SSL, or HTTP over TLS. The difference is simple: TLS is the successor of SSL. The name SSL stuck around, but what runs today is TLS.

With HTTPS the only things left unencrypted are the server domain and the port. Everything else is encrypted: the resource path, the headers, the cookies, the query parameters.

The overhead question

I won’t go into how TLS works under the hood. You might think it adds a good amount of overhead, and you’d be right. Any extra computation costs time on the client, on the server, and in the size of the packets.

However, HTTPS enables the newer HTTP/2 protocol, which is way faster than HTTP/1.1.

Why? Header compression, for one. Resource multiplexing, for another: many requests share one connection instead of waiting in line. The spec also describes server push, where the server sends resources the page will need before the browser asks, although browsers have since dropped that feature.

Details aside, HTTP/2 is a huge improvement over HTTP/1.1, and browsers only speak it over HTTPS. So HTTPS, despite the encryption overhead, ends up faster than plain HTTP if you configure things with a modern setup.