Trace a request through its real encryption boundaries

TL;DR: Mark where each connection begins, where its encryption ends and who can read the plaintext at that point. DNS, routing, TLS and application permission checks answer different questions. A valid HTTPS connection to an edge proxy does not protect a separate plaintext hop behind it.

Where you are. Module one, lesson one. You will produce the request map used in the course's final service-hardening project.

Specify one request before drawing the network

EvidenceDesk is a fictional service that accepts customer documents, extracts text in a worker and stores a result. It may later supply approved text to an AI assistant. This course reviews the network, host and credential foundations beneath that feature; no live service is needed for the exercises.

For our first case, a client uses an explicit HTTPS URL. It resolves the hostname with ordinary unencrypted DNS, opens a TLS connection to an edge proxy and validates the expected service name. The proxy decrypts the request and forwards it over plaintext HTTP to an internal API. The API dispatches work to a parser. These are deliberately specified exercise assumptions, not defaults shared by every browser or deployment.

Draw separate connection boundaries. Do not draw one continuous lock from the customer's device to the parser. The edge is a plaintext recipient, and the internal transport has a different protection decision.

The physical packet route may change without changing these logical endpoints. Name resolution may be cached, a proxy may perform it, and a client may use a different transport. Your map needs the configuration that actually applies, not an obligatory six-hop story.

What each observer can learn

TLS protects the channel under its protocol and implementation assumptions. It does not make a compromised endpoint honest. The selected edge operator, certificate-validation policy and application process remain part of the trusted design. RFC 8446 specifies TLS 1.3's authenticated channel protections; the next lesson examines peer identity in detail.

In this case, assume the TLS ClientHello is not encrypted by an additional mechanism, so the requested server name can be exposed there as well as in DNS. Do not promise that hiding DNS alone hides the destination. Conversely, do not claim every client always exposes the same handshake fields: record the actual transport and privacy configuration.

DNS privacy and authenticity are separate

Encrypted DNS protects the connection to the selected resolver. That resolver still processes the query, and an untrustworthy resolver can return a misleading address. DNSSEC allows a validating resolver or client to authenticate signed DNS data through its configured trust chain. It does not encrypt the query or turn an unsigned zone into authenticated data.

Changing a DNS answer can redirect a connection or deny service. If the client still checks the original expected TLS name, an attacker without suitable accepted credentials cannot simply substitute their own unrelated certificate. This depends on correct validation and uncompromised trust anchors; it is not a guarantee against a compromised endpoint or misissued accepted credential.

Use RFC 4033 for DNSSEC's origin-authentication and integrity properties and RFC 8484 for DNS over HTTPS. Neither replaces the other's purpose.

The first connection has a policy too

A scheme-less address does not universally start with an HTTP request. Client behavior depends on its HTTPS-first policy, stored HSTS state, preload information and fallback rules. In this course's case the URL is explicitly HTTPS, and the client does not silently retry application traffic in plaintext after certificate failure.

If a client does send an initial HTTP request, a later HTTPS redirect cannot protect the bytes already sent or stop an in-path party from replacing that response. HSTS tells a supporting client to use secure transport for a known HSTS host; prior knowledge or preload handling determines first-contact coverage. RFC 6797 defines that policy mechanism. Test the client behavior you rely on rather than inferring it from the presence of a redirect.

Fix the internal hop without overclaiming

For EvidenceDesk, require authenticated encryption between the edge and API, with the API checking the expected peer and request policy. A private address or a network segment alone does not supply confidentiality or application authorization. Segmentation can reduce who reaches the hop; it is a different control with its own enforcement and failure conditions.

Address translation is different again. Some translation and state configurations reject unsolicited inbound traffic, but explicit mappings, forwarding rules and the surrounding firewall change that behavior. Do not use “behind NAT” as an access-control requirement. State which ingress and egress connections are allowed and verify the policy that enforces them.

Turn the boundary map into a connection register

A review that records only “HTTPS enabled” cannot tell you which recipient sees the document. Give each connection its own row. The browser-to-edge connection and edge-to-API connection have different peers, keys and termination points. A proxy can authenticate its own upstream while forwarding a customer credential that the upstream must validate separately. Do not infer the customer's identity from the proxy's network location.

For this exercise, the approved recipients of document plaintext are the browser, edge, API and parser. That approval is a fictional design assumption, not a conclusion supplied by TLS. The edge may need the document to route a request, but an analytics sink does not. If logs copy the request body to a fifth system, you have added a recipient even when every connection uses TLS. Record observability exports and error queues alongside the main path.

The following offline register models the current configuration. It distinguishes encryption from successful peer verification. Values are supplied observations; the program does not perform handshakes or inspect certificates.

hops = [
    {"name": "browser-edge", "tls": True, "peer_ok": True,
     "recipient": "edge", "body": True},
    {"name": "edge-api", "tls": False, "peer_ok": False,
     "recipient": "api", "body": True},
    {"name": "api-metrics", "tls": True, "peer_ok": True,
     "recipient": "metrics", "body": False},
]
approved = {"edge", "api", "parser"}

def review(rows):
    findings = []
    for row in rows:
        if not row["body"]:
            continue
        if not row["tls"] or not row["peer_ok"]:
            findings.append(row["name"] + ": transport")
        if row["recipient"] not in approved:
            findings.append(row["name"] + ": recipient")
    return findings

print(review(hops))  # => ['edge-api: transport']
fixed = [dict(row) for row in hops]
fixed[1].update(tls=True, peer_ok=True)
print(review(fixed))  # => []
fixed[2]["body"] = True
print(review(fixed))  # => ['api-metrics: recipient']

An empty list means only that these rows satisfy this policy. It says nothing about an omitted fallback route, a stale deployment or authorization inside the API. Attach each row to a configuration revision and a controlled observation. Include an allowed request, a wrong-peer fixture and an upstream TLS failure. The failure case should show a bounded error, not a retry over plaintext.

Interpret a failed rollout

Suppose the API certificate is renewed and the edge rejects it. Preserve verification and investigate the trust chain, expected service name, validity period and deployed configuration. Record which callers fail and whether retry traffic grows. Disabling verification converts an availability problem into an unreviewed identity decision.

Finally, trace headers independently from bodies. A session cookie intended for the first-party application should not automatically follow an outbound OCR request. Define a new credential for the destination and an allowlist of required headers. A connection register becomes useful when it identifies these transformations, not merely the presence of a lock icon.

Do this before moving on

Produce a connection table for the case with endpoints, plaintext readers, peer validation and application authorization. Change two assumptions: the resolver connection becomes encrypted, and the edge-to-API hop gains validated TLS. Explain exactly which observers lose which visibility.

Then compromise the edge in the thought experiment. Identify the request data it still sees and which downstream permissions must limit its actions. A complete answer distinguishes transport secrecy from endpoint trust and tenant/object access. If you substitute a real design, inspect only systems and configuration you are authorized to review.

Change the metrics row to carry only a document identifier. Explain why the code now passes and why the identifier may still require privacy controls. Add a fourth body-carrying hop and predict the result before running the fixture.

Go deeper

• Attacker positions on the network helps reason about visibility without assuming every network observer has the same powers.
• DNS security separates resolver trust, signed data and encrypted transport in more detail.
• What happens from URL to page changes the client assumptions and tests your request explanation.
• Network segmentation and egress extends the connection table to permitted service communication.

Key takeaways

• Draw distinct connections and mark each plaintext endpoint.
• DNS privacy, DNS authenticity and TLS service identity are different properties.
• First-contact HTTPS behavior depends on explicit client policy and prior state.
• Internal transport and application permission checks remain separate responsibilities.