The HTTPS protocol

HTTP is insecure by design.

When you open your browser and ask a web server to send you a webpage, your data performs 2 trips: 1 from the browser to the web server, and 1 from the web server to the browser.

Then, depending on the content of the web page, you might have more connections required to get the CSS files, the JavaScript files, images, and so on.

During any of those connections, any network your data is going to cross can be inspected and manipulated.

The consequences can be serious: you might have all your network activity monitored and logged, by a 3rd party you are not even aware it exist, some networks might inject ads, and you might be subject to a man-in-the-middle attack, a security threat where the attacker can manipulate your data and even impersonate your computer over the network. It’s very easy for someone to just listen to HTTP packets being transmitted over a public and unencrypted Wi-Fi network.

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

Privacy and security are a major concern in today’s internet. A few years ago, you could get away with just using an encrypted connection in login-protected pages, or during an e-commerce checkout. Also because of SSL certificates pricing and complications, most websites just used HTTP.

Today HTTPS is the default. According to Google’s HTTPS transparency report, 95% to 99% of navigations in Chrome use HTTPS, and the number has been there since 2020. Browsers mark plain HTTP pages as “Not secure”, and starting with Chrome 154 Chrome asks for permission before loading a public site over plain HTTP. Many browser features, like service workers, geolocation and push notifications, only work in a secure context. HTTPS is mandatory on every site now.

When using HTTP the default server port is 80, and on HTTPS it’s 443. It does not need to be explicitly added if the server uses the default port, of course.

HTTPS is also sometimes called HTTP over SSL, or HTTP over TLS.

The difference between the two is simple: TLS is the successor of SSL.

When using HTTPS, the only thing that is not encrypted is the web server domain, and the server port.

Every other information, including the resource path, headers, cookies and query parameters are all encrypted.

I won’t go in the details of analyzing how the TLS protocol works under the hoods, but you might think it’s adding a good amount of overhead, and you would be right.

Any computation that’s added to the processing of network resources causes overhead both on the client, the server, and to the transmitted packets size.

However HTTPS enables the use of the newest protocols HTTP/2 and HTTP/3, which are much faster than HTTP/1.1.

Why? There are many reasons: header compression, multiplexing many requests on one connection, and better handling of packet loss on HTTP/3 (which runs over QUIC).

You might also read about HTTP/2 server push, where the server sends resources before the browser asks for them. Chrome removed it in version 106, so don’t count on it. If you want to tell the browser about important assets early, the modern option is the 103 Early Hints status code. There’s more on this in the HTTP/2 post.

Details aside, HTTP/2 and HTTP/3 are a big improvement over HTTP/1.1, and both need HTTPS: browsers only speak HTTP/2 over TLS, and HTTP/3 runs over QUIC, which has TLS 1.3 built in. So despite the encryption overhead, HTTPS ends up faster than plain HTTP when the server is set up with a modern stack.

Want me to talk about your product? You can sponsor this site.