HTTP in 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.
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 a requirement on any site. More than 50% of the whole Web uses it now. Google Chrome recently started marking HTTP sites as insecure, just to give you a valid reason to have HTTPS mandatory (and forced) on all your websites.
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 protocol HTTP/2, which has a huge advantage over HTTP/1.1: it way faster.
Why? There are many reasons, one is header compression, one is resource multiplexing. One is server push: the server can push more resources when one resource is requested. So, if the browser requests a page, it will also receive all the resources needed (images, CSS, JS).
Details aside, HTTP/2 is a huge improvement over HTTP/1.1 and it requires HTTPS. This means that HTTPS, despite having the encryption overhead, happens to be way faster than HTTP, if things are properly configured with a modern setup.
More network tutorials:
- Introduction to WebSockets
- How HTTP requests work
- The HTTP Request Headers List
- The HTTP Response Headers List
- HTTP vs HTTPS
- What is an RFC?
- The HTTP protocol
- The HTTPS protocol
- The curl guide to HTTP requests
- Caching in HTTP
- The HTTP Status Codes List
- What is a CDN?
- The HTTP/2 protocol
- What is a port
- DNS, Domain Name System
- The TCP Protocol
- The UDP Protocol
- An introduction to REST APIs
- How to install a local SSL certificate in macOS
- How to generate a local SSL certificate
- How to configure Nginx for HTTPS
- A simple nginx reverse proxy for serving multiple Node.js apps from subfolders
- What is a reverse proxy?