How systems communicate: network, DNS, HTTP, and TLS

A request is a relay race

When a Riverstone customer opens https://track.riverstone.example, several independent jobs run. The browser asks Domain Name System (DNS) servers which internet protocol (IP) address currently belongs to that name. The operating system opens a connection to that address and port, usually 443 for HTTP over TLS (HTTPS). Hypertext Transfer Protocol (HTTP) then names the method, path, headers, and body: GET /shipments/8821, plus cookies and an authorization header. Transport Layer Security (TLS) wraps that HTTP conversation so eavesdroppers on the cafe Wi-Fi should not be able to read or silently alter it.

MDN’s HTTP overview is a practical map of methods, status codes, and headers. RFC 8446 defines TLS 1.3, the common modern handshake. You do not need to memorize every record type. You do need to know that “the site loaded” is not one event. DNS can lie, the IP can belong to a different service, HTTP can send secrets in a query string, and TLS can be correct for a name that is not the company you thought you typed.

What each layer protects, and what it ignores

DNS answers the question “which address should I contact for this name?” It does not prove the application is honest. A poisoned or hijacked answer can send a customer to an attacker-controlled host. HTTP describes the application request: it can leak identifiers in URLs, cache sensitive responses, or send session cookies without the Secure flag. TLS 1.3 encrypts application data and provides a cryptographic handshake so the client can check a certificate for the name it intended to reach.

TLS does not decide who the human is. A perfect TLS session to TrackPort still needs authentication of the customer and authorization of that customer’s shipments. TLS also does not hide the destination IP, the server name indication in many deployments, or the fact that a connection happened. If Maya later inspects a proxy log, she may see that a laptop connected to track.riverstone.example without seeing the HTML. That is expected, not a failed capture.

• Network reachability: can packets arrive at this address and port?
• DNS: which address did the name map to, and who could have answered?
• HTTP: what did the application mean, including cookies, tokens, and cache behavior?
• TLS: confidentiality and integrity of the bytes, plus certificate checks for a name, not authorization of a person.

Worked trace: a customer checks a pallet

Priya asks a customer to watch shipment 8821. The customer’s phone resolves track.riverstone.example, connects to 443, completes a TLS 1.3 handshake with a certificate for that name, and sends GET /shipments/8821 with a session cookie. Sharing Wi-Fi alone cannot expose properly authenticated TLS contents. If contents leak, investigate endpoint compromise, trusted interception proxies, and connection configuration. If the page is the attacker’s login lookalike but the certificate is for track-riverstone-login.example, the failure started at the name the user trusted, not at “encryption is fake.”

If the certificate is valid for track.riverstone.example but the DNS answer pointed at an attacker who obtained a certificate, you are in a harder case involving name control or a compromised certificate authority. Do not collapse those cases. Say which check failed. That habit will matter when SOC lessons ask whether a log line is evidence of spoofing, credential theft, or a mis-typed URL.