Transparent redirection sends an unproxyable agent's 443 traffic to the proxy - what breaks, and what does an implant on that host still get?

## The move When software cannot be told a proxy exists, the network can be told instead. At the first-hop gateway or the switch port the device is on, traffic to certain ports is redirected to the proxy rather than routed to its destination. The client believes it is talking to the vendor. The proxy accepts the connection, works out the intended destination, and opens its own session outward. Nothing was configured on the endpoint, which is the entire appeal on a plant floor where the endpoint cannot be configured at all. ## What has to be true for it to work **The traffic must be a protocol the proxy understands.** Redirection is address-level; comprehension is not. Port 443 is a convention, not a guarantee. Vendor telemetry and machine-tool protocols on 443 that are not HTTP arrive at a proxy that cannot parse them and are dropped or mangled. **TLS must be re-originatable.** To see inside, the proxy terminates the client's TLS and presents a certificate the client will accept, then makes its own session onward. That requires the client to trust an internal certificate authority. A device you cannot configure is usually a device whose trust store you cannot add to. **The client must not pin.** Certificate pinning means the agent accepts only the vendor's own certificate or issuer. Re-origination fails by design - and it fails *silently from the network's point of view*: the handshake aborts, the agent retries, telemetry stops, and the first symptom is a vendor support call or a stopped queue rather than an alert. **The client must not be authenticating with its own certificate.** If the agent presents a client certificate to the vendor, a middle box that terminates the session has no way to prove possession of that key onward. Mutual authentication and interception are mutually exclusive. **You want a name, not an address.** If the agent connects to a compiled-in address, there is no server name in the handshake to key policy on, so even a successful interception leaves you filtering by address. Where the agent does use a name, the server name in the ClientHello is visible at the gateway even without interception - which is the cheap middle option worth naming in an interview: redirect nothing, but log and filter on the name. ## What you lose even when it works In explicit mode a proxy knows which client asked, and often which user. In transparent mode it knows a source address. On a floor where addresses are handed out by DHCP and machines are replaced by identical machines, that is a weaker record than it looks, and it is the reason a transparent deployment produces logs that are harder to attribute than the explicit deployment covering the rest of the estate. ## What the implant still gets Redirection covers exactly the ports and protocols you enumerated in the redirect. Everything else on that host takes the ordinary route out: | what you redirected | what remains untouched | | --- | --- | | TCP/443 and TCP/80 | any other TCP port, including 8443 and 8080 | | TCP only | UDP, QUIC on UDP/443 included | | this device's addresses | traffic the device sends after its address changes | QUIC deserves the explicit mention because it is the one people miss: it runs over UDP, so a redirect written for TCP does not apply, and a client that finds UDP/443 open will happily use it. The usual companion control is to block UDP/443 outbound so clients fall back to TCP where the redirect lives - a deliberate cost, paid in performance, to keep the traffic in a place you can see. And then the failure path. When pinning or client-certificate authentication breaks the agent, the operational answer is an exemption for that device. So interception does not eliminate the standing exception; it *reduces the number of them*, and the ones that survive are on the devices whose software was most determined not to be inspected. An implant looking for a way out of that estate goes to exactly those hosts, because their exemption is written down, permanent, and attached to a business function no one will switch off. ## Answering it well Say what redirection is in one sentence, list the four conditions that must hold (parseable protocol, installable trust, no pinning, no client certificate), name what you lose regardless (client identity), and close on scope: the redirect is a list of ports, and everything not on that list, plus every device you had to exempt, is what remains available to anything running on those machines.