Your proxy logs TLS SNI for a CDN hostname sanctioned apps also use — what can that metadata still distinguish?

## What is actually on the wire When a client opens a TLS session, the ClientHello is sent before any encryption is established. It carries the Server Name Indication extension — the hostname the client wants — plus cipher suites, extensions, supported groups and ALPN. That is why SNI is the workhorse of network-side visibility: it is a *name*, and names are what detections and blocklists are written against. What else a passive sensor sees depends on the version. On TLS 1.2 the server's Certificate message is sent in the clear, so the subject and subject-alternative names are readable. On TLS 1.3 the certificate is encrypted, and a tap is left with the SNI alone. Encrypted ClientHello (ECH) goes one step further and encrypts the SNI itself, at which point the network record holds a destination address and nothing nameable. An explicit forward proxy is a different observation position from a tap, and this distinction is worth stating in an interview. Even without decryption it logs the CONNECT target hostname and port, the client address, the authenticated user if proxy authentication is on, the byte counts and the duration. The *client* side of a proxy record is far richer than anything a passive sensor produces. ## Why the shared hostname defeats the name A content delivery network serves thousands of tenants from the same hostnames and the same address ranges. Fronting exploits exactly this: the outer connection is opened to a hostname that everyone uses, and the inner HTTP request — inside the encrypted body — names the tenant that actually answers. Your record is entirely accurate and entirely undiscriminating; blocking the name would break sanctioned services, and allowing it lets everything through. This is the general lesson of the leaf applied to one surface: **a metadata field is only as useful as its ability to separate two populations.** The SNI separates `some-cdn.example` from `evil.example` perfectly, and separates two tenants of `some-cdn.example` not at all. ## What still discriminates - **Client identity and population rarity.** The proxy names the host and the user. A CDN hostname contacted by four thousand workstations is background; the same hostname contacted by one build server that has no reason to run a browser is a fact about the *client*, not the destination. - **The TLS client fingerprint.** Hashes of selected ClientHello fields, such as JA3 or JA4, characterise the client's TLS stack. A connection to a browser-shaped hostname made by a stack that is not the managed browser is a discrepancy worth pulling. It is a weak signal on its own — fingerprints collide, libraries are shared, and a determined implant can mimic one — so treat it as a lead rather than a verdict. - **The destination address and network.** Even when the name is shared, the resolved address, the network it belongs to, and whether the client resolved a name before connecting are recorded facts. A connection to an address the client never looked up is anomalous regardless of what the SNI said. - **The endpoint.** Network-connection telemetry on the host names the process that opened the socket, which is the one field that cuts through the shared hostname entirely. When the network surface saturates, attribution moves to the endpoint. ## The decision the answer is really about The tempting response is "intercept the TLS". TLS interception at the proxy does restore full visibility, and it is a genuine option in some estates, but it is a policy and risk decision rather than a reading of the record — certificate pinning breaks, privacy and legal constraints bite, and the interception point becomes a high-value target. What an interviewer wants to hear first is that you know why the field failed to discriminate and where the discriminating signal moved to, not a reflex to decrypt everything. ## Planning for the name to disappear ECH deployment makes this trajectory permanent rather than exceptional. Detections written against hostnames will quietly lose coverage, and the loss will look exactly like a quiet estate, because a rule that has nothing to match produces no output. The defensive answer is to rebalance: keep name-based network signals where names still exist, and build the durable detections on process-to-destination relationships from endpoint telemetry, which sit below the encryption entirely.