Networks in one request: DNS, TCP, TLS, and HTTP

One telemetry request from an untrusted Wi-Fi network

Imagine Meridian flight engineer Dax Mercer opening https://telemetry.chronos.orbital/v2/passes from a conference hotel Wi-Fi network to check an upcoming satellite pass. Every packet Dax’s laptop sends crosses an untrusted local access point, an ISP router, and public transit links before reaching Meridian’s edge.

When a junior engineer says "HTTPS secures the connection," they often blur four separate jobs into one word. To debug outages or design network controls accurately, you have to watch the four protocol stages execute in order.

The four-stage relay: DNS, TCP, TLS, and HTTP

First, DNS translates the human-readable name telemetry.chronos.orbital into an IP address such as 198.51.100.42. Standard UDP/TCP port 53 DNS queries travel in cleartext unless DoH (DNS over HTTPS) or DoT (DNS over TLS) is configured, and DNSSEC only signs the record for integrity rather than hiding the query.

Second, TCP opens a reliable, ordered byte stream between Dax’s ephemeral client port and the server’s port 443 using the three-way handshake (SYN, SYN-ACK, ACK). Third, TLS runs over that TCP socket to negotiate ephemeral keys and validate the server’s X.509 certificate against telemetry.chronos.orbital. Fourth, HTTP sends the GET /v2/passes verb, headers, and bearer token inside the encrypted TLS record layer.

What TLS protects and what it leaves exposed

Once the TLS 1.3 handshake finishes, an eavesdropper on the hotel Wi-Fi cannot read the URL path (/v2/passes), the Authorization header, or the JSON response body. Nor can the attacker modify a byte in transit without breaking the AEAD authentication tag and causing the receiver to drop the connection immediately.

However, TLS is not a magic cloak over the entire network stack. The IP packet headers must remain visible so routers can forward traffic, and in standard TLS 1.3 the ClientHello includes the Server Name Indication (SNI) extension in cleartext so the server knows which certificate to present. An observer on the local network still knows that Dax’s IP address connected to telemetry.chronos.orbital on port 443 and transferred 48 kilobytes of data.

Transport trust is not application authorization

A valid TLS padlock proves that the browser is talking to a server holding the private key for telemetry.chronos.orbital and that the channel between them is encrypted. It says nothing about whether the server itself is honest (attackers obtain valid certificates for phishing domains every day) and nothing about who the client user is (unless mutual TLS client certificates are enforced).

Furthermore, TLS delivers whatever HTTP payload the client sends directly to the application parser. If Dax’s bearer token is stolen by malware on the laptop, or if the API endpoint forgets to check whether Dax is authorized to read another satellite’s pass schedule, TLS will faithfully encrypt the exploit and encrypt the leaked response.

Diagnosing failures by layer

Separating the four stages makes troubleshooting deterministic. NXDOMAIN means DNS failed before a single packet reached the server IP. A connection timeout or immediate RST on port 443 means TCP reachability or a network firewall blocked the socket before TLS started. ERR_CERT_COMMON_NAME_INVALID means TCP connected, but TLS rejected the certificate binding. And an HTTP 401 Unauthorized or 403 Forbidden proves that DNS, TCP, and TLS all succeeded, and the application gate rejected the caller’s identity or permissions.