Your TLS decryption exemption list has grown to two hundred destinations — what has that cost, and how would an intruder use it?

## Why the list exists at all An inspection point that decrypts TLS terminates the client's session, opens its own to the server, and re-signs with an authority the managed fleet trusts. Some traffic cannot go through that, and the reasons are legitimate: - **Clients that pin.** A mobile or desktop application that expects a specific chain sees a substituted one and refuses. It does not degrade — it fails, usually with an opaque error, and the vendor's support line will tell your users to disable inspection. - **Mutual TLS.** If the server demands a client certificate, the interception point does not hold the client's private key and cannot complete the handshake on its behalf. - **Legal and agreement-driven categories.** Banking, health, tax and similar categories are commonly exempt because an employment agreement, a works council, or a regulator says employee personal traffic in those categories is not to be read. - **Applications that are simply too fragile,** including embedded devices and appliances whose trust store you cannot change. None of that is a mistake. The mistake is treating the list as a static side effect instead of as a managed part of the blind share. ## The ratchet Adding an entry is cheap: an application broke, someone raised a ticket, the entry went in and the ticket closed. Removing an entry is expensive: you must find who depends on it, retest the application against a current release, and accept the risk that you break something in production. So the list grows monotonically. Two hundred entries is not two hundred deliberate decisions; it is two hundred incidents that were resolved the fastest way available, and the resulting blind share is a number nobody ever agreed to. The review burden is the second cost. Somebody has to be able to say what each entry is for, who asked, when it was last needed, and whether the client that forced it still behaves that way. Without an owner and an expiry, entries outlive the applications that caused them. ## Where the decision is actually taken — the part candidates miss To bypass a flow you must decide *before* you terminate it, which means at the ClientHello. The evidence available at that moment is: the destination address, and the `server_name` the client wrote. Both are supplied by the party you are trying to make a decision about. That is the sharp end. A category-based bypass says "do not decrypt anything classified as banking". Classification is applied to a name — a name the client chose to send. A destination that resolves into a bypassed category, or a tenant on a shared hosting front that the category database already trusts, inherits the exemption for free. An intruder is not defeating the control; they are reading your policy and standing on the side of it you told your device not to look at. Address-based exemptions fare no better: shared and anycast addresses mean an exempted address may serve far more than the service you meant to exempt. ## Making the list smaller instead of complaining about it The practical work is the same shape everywhere: | Move | What it buys | What it costs | |---|---|---| | Attach an owner and an expiry to every entry | The list stops being permanent | Someone must run the review | | Replace category bypasses with named destinations | Removes the open-ended class | More entries, more churn | | Re-test pinned applications at each vendor release | Some entries can go | Test effort per release | | Rank entries by bytes and by last hit | Kills dead entries first, cheaply | Needs accounting from the device | | Push the fragile client to a managed endpoint control | Recovers plaintext elsewhere | Only covers managed devices | Rank by evidence, not by fear. An entry that has carried no traffic in ninety days can be removed with a rollback plan and almost no risk; an entry carrying a quarter of your bypassed bytes needs a conversation with the application owner, not a unilateral deletion. ## What you can still say about a bypassed path You did not lose the flow, only its contents. Destination, volume, direction, duration and session counts are still recorded, and a bypassed destination that suddenly carries a very different volume profile than it did last quarter is a legitimate thing to notice. It is weaker evidence than payload, and it must be reported as such: the path was bypassed by policy, so the absence of a finding on it proves nothing at all about what crossed it. ## The framing that lands in interviews Say out loud that the exemption list *is* a security control's cost line, not an administrative annoyance: it is the part of your blind share you chose, as opposed to the part client vendors chose for you. A candidate who can separate those two — the exemptions you granted and the encryption you cannot break — is describing a defensible position rather than a device configuration.