HTTP and HTTPS: How the Web Talks

What HTTP actually is

HTTP stands for HyperText Transfer Protocol. It is an application layer protocol sitting at layer 7 of the OSI model. It runs on top of TCP, which handles reliable delivery, which in turn runs on top of IP, which handles routing. HTTP itself knows nothing about any of that. Its job is a simple exchange: a client sends a request and a server sends back a response.

The request and response are both plain text messages. A request says what the client wants: which method it is using, which URL it is targeting, what headers it is sending along. The response tells the client what happened: a status code that summarises the outcome, a set of headers describing the response and usually a body containing the actual content.

That exchange happens over port 80 for HTTP. HTTPS uses port 443. Both ports are well-known assignments that clients use by default when no explicit port appears in the URL.

HTTP methods

The method tells the server what the client wants to do with the resource at the given URL. Browsers only use GET for navigation. Everything else, the form submissions, the API calls, the deletions, come from JavaScript running on the page.

Status codes

Every HTTP response starts with a three-digit status code. The first digit tells you the category. The remaining two digits narrow it down to the specific outcome. Knowing the five groups is usually enough to orient yourself quickly when something goes wrong.

The problem with plain HTTP

HTTP traffic is plain text. Every request, every response, every cookie, every form field travels across the network in a format that anyone positioned between the client and server can read without any special tools.

On a public Wi-Fi network this is straightforward to exploit. The router handling your traffic sees everything. Anyone else on the same network running a packet capture can see it too. An ISP routing your traffic sees it in full. A malicious node anywhere along the path between you and the server has complete visibility into both what you are requesting and what the server is returning.

The payload being readable is one part of the problem. The other part is that plain HTTP gives you no way to verify you are actually talking to the server you think you are. An attacker in a position to intercept traffic can also modify it in transit, sending back a different response to your request without either side noticing. This is known as a man-in-the-middle attack.

What HTTPS adds

HTTPS is HTTP with TLS underneath it. TLS stands for Transport Layer Security. It sits between the application layer and the TCP layer, wrapping the HTTP exchange in an encrypted tunnel before anything leaves the machine.

TLS solves three separate problems at once. It encrypts the traffic so that eavesdroppers cannot read it. It authenticates the server through a certificate so the client knows it is talking to the right destination. It also checks the integrity of every message so that tampering in transit is detectable.

The TLS handshake

Before any HTTP request can be sent over HTTPS, the client and server run a TLS handshake. This is a separate negotiation that happens after the TCP connection is established. Its purpose is to agree on encryption parameters and establish shared session keys that neither side ever transmits directly.

All of this happens before the first byte of HTTP data moves. In TLS 1.3, the current version, the whole handshake completes in a single round trip. Previous versions needed two. That extra round trip was one of the performance arguments against HTTPS in the early days. With TLS 1.3 that argument is gone.

Certificates and Certificate Authorities

A TLS certificate is a digital document. It contains the domain name it is valid for, a public key, an expiry date and a digital signature from a Certificate Authority. The signature is what makes the certificate trustworthy.

Certificate Authorities are organisations that have gone through a vetting process to have their own certificates included in the trust stores shipped with operating systems and browsers. When a server presents a certificate signed by one of these authorities, your browser can verify the signature using the CA's public key and confirm the certificate is genuine.

This creates a chain of trust. The CA vouches for the server. Your device trusts the CA. Therefore your device trusts the server. The browser checks that the domain in the certificate matches the domain in the URL. A certificate for one domain cannot be used to impersonate a different one.

HTTP versions

HTTP has gone through several major versions. Each one kept the same request and response model while changing how that exchange travels across the network.

From a developer perspective the differences are mostly invisible. You write the same HTTP request regardless of version. The browser negotiates which version to use during connection setup. Most modern servers support HTTP/2 at minimum. HTTP/3 adoption is growing but still not universal.