The Unproxyable Estate

## What "proxy-aware" actually means An egress proxy only sees traffic that was *sent to it*. Nothing about a proxy is imposed on a client by the client's own stack: the application decides to open its connection to the proxy's address instead of the destination's, and asks the proxy to reach the destination on its behalf. That decision is made from configuration the application chose to read. If it reads no configuration, it dials the destination directly, and the proxy never learns the session existed. ## The three conventions, and where each one leaks **The operating-system proxy setting.** Platforms expose a system-wide proxy that the platform's own HTTP client honours. Browsers and anything built on the platform stack pick it up. Software that ships its own HTTP implementation, or that speaks a non-HTTP protocol, does not. **A PAC file, located by configuration or by WPAD.** A proxy auto-config file is a small script the client fetches and evaluates per destination, returning "go direct" or "use this proxy". WPAD is the discovery convention that lets a client find that file without being told where it is. Both are entirely voluntary on the client's side - and a client that will fetch and run a script it discovered on the network is itself a thing an attacker likes, which is one reason discovery is often disabled in favour of an explicit URL. **Environment variables.** `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` (with their lower-case spellings) are honoured by a large amount of command-line tooling and by many language HTTP libraries. They are a *convention*, not a rule: each library decides whether to read them, which spelling wins, and how `NO_PROXY` matching works. They are also set per process, so a variable exported in an interactive shell does not reach a service started by the init system. ## Why a vendor agent honours none of them The unproxyable estate is not badly written software so much as software written for a different assumption. A machine-tool vendor's diagnostic agent, an instrument's telemetry uploader, a licence-server check-in client: these are built to reach one endpoint the vendor controls, often with the destination compiled in, sometimes as a bare address rather than a name, frequently over a proprietary protocol on a well-known port, and occasionally with the vendor's certificate pinned so that anything sitting in the middle is refused by design. There is no setting to change because the vendor never modelled a customer who inspects egress. The honest test in an interview is: can you *state* the failure rather than wish it away? "We push proxy settings by policy" is a good answer for laptops and a wrong answer for the plant floor. ## The exception, and why it is the interesting part When a device cannot be taught the proxy and cannot be intercepted, the outcome is always the same artefact: a named rule in the rule base permitting that source to reach that destination directly. It is written on enforcement day, under time pressure, by someone who needs the line running. Three properties make it worth talking about: 1. **It is keyed on the host, not on the program.** A packet filter matches addresses, ports and protocols. It cannot distinguish the vendor agent's socket from any other socket on the same machine. An implant that lands on that host is inside a permission somebody already granted. 2. **It removes the record, not just the control.** For every other host you have a proxy log with the requested host name, the verdict and the volume. For this one you have flow records - source, destination, ports, protocol, byte and packet counts, timestamps - and no payload at all. You can show that bytes moved; you cannot show what they were. 3. **It outlives its reason.** It is named after a vendor, its author has moved on, and the business function it protects is undocumented. Nobody removes it because nobody can prove what stops working, which is exactly why the rule should be written down with an owner, a date and a stated business dependency at the moment it is created. ## What an adversary does with it An implant does not need to defeat egress filtering if one host in the estate is exempt from it. Choosing the machine whose direct-egress rule is written into the rule base for vendor reasons costs the adversary nothing and buys a path that generates no proxy entry, sits in a rule an operator is scared to touch, and blends with traffic the business genuinely depends on. That is the whole reason this leaf exists: the exception is a control decision with a standing price, not a paperwork detail. ## Answering it well Name the three mechanisms, say plainly that all three are opt-in, give a concrete class of software that reads none of them, and finish on the consequence: the exception is scoped to a host, so it belongs to every process on that host, and the traffic that uses it is invisible in the one log you would otherwise reach for.