HTTP and TLS

Why it matters

Almost every application talks over HTTP, and almost all of that traffic is protected by TLS (HTTP over TLS is HTTPS). APIs, cloud consoles, database admin panels and model-serving endpoints all use it. Reading status codes and headers is a daily debugging skill, and understanding certificates helps you fix "your connection is not private" errors and spot attacks.

HTTP: requests and responses

HTTP is a text-based request/response protocol. The client sends a request:

GET /docs/start HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html

The server sends a response:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: max-age=3600
Content-Length: 5120

<!doctype html> ...

Methods say what the client wants: GET reads, POST creates or submits, PUT/PATCH update, DELETE removes.

Status codes are grouped by the first digit:

HTTP is statelessDescribes HTTP: each request stands alone, so sessions rely on cookies sent back with each request.: each request stands alone. Logins work by the server setting a cookie that the browser sends back on later requests.

Versions: HTTP/1.1 sends one request at a time per connection, HTTP/2 multiplexes many over one TCP connection, and HTTP/3 runs over QUIC on UDP.

The problem TLS solves

Plain HTTP crosses many networks (your Wi-Fi, your ISP, other carriers). Anyone on the path could read passwords or change the page. TLS provides three things:

1. Confidentiality: traffic is encrypted.
2. Integrity: tampering is detected.
3. Authentication: you are talking to the real example.com, proven by a certificateA signed file that binds a public key to one or more names, proving a server's identity..

Certificates and trust

A certificate binds a public key to one or more names (listed in the Subject Alternative Names). It is signed by a certificate authority (CA)An organisation trusted by browsers and operating systems to sign certificates.. Your operating system and browser ship with a list of trusted root CAs. Sites usually send a chainThe leaf certificate plus intermediate certificates linking it to a root CA the browser already trusts.: their leaf certificate plus an intermediate certificate, which was signed by a root you already trust.

The browser checks that:

• the chain leads to a trusted root,
• the name you typed matches the certificate,
• today is within the validity dates,
• the certificate has not been revoked.

Free CAs such as Let's Encrypt issue certificates valid for 90 days or less and renew them automatically, so expiry problems are usually an automation failure.

The TLS 1.3 handshake, simplified

1. ClientHello: the browser lists supported cipher suites and sends a key share.
2. ServerHello: the server picks a cipher suite, sends its key share, its certificate and a signature proving it holds the private key.
3. Both sides compute the same session keysSymmetric keys both sides compute during the TLS handshake and use to encrypt the rest of the connection. from the key shares (a Diffie-Hellman exchange). From here on, everything is encrypted with fast symmetric encryption.
4. The HTTP request travels inside the encrypted tunnel.

TLS 1.3 needs one round trip before data flows; TLS 1.0 and 1.1 are obsolete and disabled by modern browsers.

What an observer still sees

With HTTPS, someone on your network cannot see page contents, paths, cookies or form data. They can still see your IP address, the server's IP address, timing and volume, and usually the site's name (from DNS and the Server Name Indication field), unless encrypted DNS and Encrypted Client Hello are in use.

Worked example: reading a failure

A user reports NET::ERR_CERT_DATE_INVALID. You open the certificate and see it expired yesterday: the renewal job failed. A different error, ERR_CERT_COMMON_NAME_INVALID, would mean the certificate does not list the name used, for example a certificate for example.com served on api.example.com.

Common mistakes

• Treating the padlock as "safe site". It means the connection is encrypted to that name; phishing sites have valid certificates too.
• Clicking through certificate warnings on public networks.
• Mixing HTTP resources into an HTTPS page (mixed content), which browsers block.
• Reading 401 and 403 as the same. 401: not authenticated (log in); 403: authenticated but not allowed.

Quick recap

• HTTP: methods, status codes, headers; stateless, with cookies for sessions.
• TLS adds encryption, integrity and server authentication.
• Certificates chain up to a trusted root CA and must match the name and dates.

Try it

Open the Do tab to inspect a certificate and real HTTP traffic in your browser.