Skip to main content
Back to module
Networking Fundamentals · Core Network Services

HTTP and TLS

Reading40mLesson 3 of 3 in this module

Follow an HTTP request and response, explain what TLS adds, and inspect a website's certificate in your browser.

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:

RangeMeaningCommon examples
2xxsuccess200 OK, 201 Created, 204 No Content
3xxredirect or cached301 Moved Permanently, 302 Found, 304 Not Modified
4xxclient error400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests
5xxserver error500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout

HTTP is stateless: 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 certificate.

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). Your operating system and browser ship with a list of trusted root CAs. Sites usually send a chain: 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 keys 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.

Also in this lesson: