The Shrinking Readable Share

## What an on-path device actually holds When your border forwards a TLS session it cannot decrypt, it still records a lot: source and destination address, source and destination port, the transport, when the session started and ended, how many bytes and packets went each way, and the shape of that traffic over time. None of that is payload. A flow record proves **bytes moved between two addresses at a time**; it never proves what those bytes were. On top of that, the TLS handshake itself has historically leaked one very useful field in cleartext: the `server_name` extension (SNI) in the ClientHello. The client sends it before any keys exist, because the server needs it to pick which certificate to present. For roughly a decade that field has been the backbone of name-based policy on devices that do not decrypt — allow, deny or categorise by the name the client asked for. ## What encrypted client hello removes Encrypted client hello (ECH) closes that leak. The client builds two ClientHellos: an *outer* one, sent in cleartext, whose `server_name` is a public name belonging to the provider that fronts many sites; and an *inner* one, encrypted to a public key the client obtained ahead of time, carrying the real `server_name`, the real `alpn` and the rest of the sensitive parameters. An observer sees the outer name and nothing else. If the client also resolves names over an encrypted channel, you do not see the lookup that preceded the connection either — the name disappears from both places at once. So the loss is not "some of the name": it is the name. ## The fallback that does not exist The most common wrong answer from an experienced engineer is: *fine, read the certificate the server returns and take the subject or the SAN list.* That works on TLS 1.2, where the server's Certificate message is in the clear. It does not work on TLS 1.3. In TLS 1.3 the server sends ServerHello, both sides derive handshake keys immediately, and everything after that — EncryptedExtensions, Certificate, CertificateVerify — is encrypted. There is no certificate subject on the wire to fall back on, with or without ECH. Any design that assumes a cleartext certificate is designing for a version of TLS that is being retired underneath it. ``` TLS 1.3 ClientHello, no ECH — readable at the border server_name api.partner.example # the real destination alpn h2 Same client offering encrypted client hello server_name front.provider.example # outer: a shared public name encrypted_client_hello <opaque> # real server_name and alpn are inside After ServerHello, TLS 1.3 encrypts the rest of the handshake Certificate <encrypted> # no subject or SAN to read ``` ## Why the address is a weak substitute Once the name is gone, the address is what you have, and modern hosting has deliberately blunted it. A single anycast address can front tens of thousands of sites across many customers; the same address may serve a payroll provider and a malware operator's rented tenant in the same hour. "Connections went to 203.0.113.10" is true and nearly useless as a verdict. Volume and timing still say something — a long-lived low-rate session with regular beacon-like spacing looks different from a bulk download — but that is inference over shape, not identification, and it produces candidates rather than conclusions. ## What it costs you, which is the part interviews probe Every answer here has a bill attached. - **Accept it.** Your readable share falls, and it falls for reasons you do not control: client vendors ship ECH, applications adopt it silently, and the traffic you can name shrinks month over month. - **Exempt the client.** You add another permanently unread path, and exemption lists only grow. - **Force the client to negotiate through you.** Some clients refuse: they pin what they expect, or they simply fail. A hard failure is a broken business application and an outage somebody has to own. - **Change vantage.** Inspect where the plaintext still exists — on the endpoint, or at the service you control. That sees more, and it only covers devices you manage; contractors, appliances and unmanaged hardware are outside it by construction. ## The claim discipline State conclusions in the direction the evidence supports. From an opaque TLS flow you may assert that a host on your network established an encrypted session to an address, when, for how long, and how much data moved in each direction. You may not assert which site it was, which application, or what was transferred. Candidates who blur that line write incident notes that do not survive being questioned.