Three places to stand in a TLS path
To upgrade a connection to post-quantum crypto when you control neither the client nor the server, you first have to get into the path. There are three places to stand, and each trades something away — platform reach, a line of config, or who ends up holding the flow control. Only one of the three is invisible to both ends at once, and that is the one worth understanding first.
Inline — at the packet layer
The agent attaches to a network interface with an eBPF program on the kernel's TC (traffic-control) hook, Linux 4.9 and up. It reads, rewrites, and re-emits packets in place and never opens a socket for the spliced flow. Nothing is configured, routed, or moved on either side — no proxy variable, no CONNECT, no vacated port. The two TLS endpoints don't know it is there; they simply negotiate, and what they get is the two-handshake splice with the crypto swapped in the middle. This is the only transport transparent to both ends simultaneously, which is exactly why we lead with it. The cost is reach: it is Linux-only, the agent must sit in-path on the host's interface, and because it works below the kernel's TCP stack it has to own its own flow control — a deliberate trade with consequences of its own.
Redirect — netfilter into a real socket
One step up the stack. An iptables nat rule — a REDIRECT in the OUTPUT chain for a host's own outbound clients, or a PREROUTING DNAT for traffic arriving at a gateway — diverts port-443 connections to a local listener; the agent recovers the original destination with SO_ORIGINAL_DST and dials it on 443. The client still changes nothing, and the server keeps its port. What differs from inline is underneath: the diverted connection lands on a real kernel socket, so the agent inherits the kernel's TCP stack — and its flow control — for free. The price is that it needs root and a netfilter rule on the host or gateway where it stands. Linux again, just at the socket layer rather than the packet layer.
Proxy — an endpoint the traffic is pointed at
The portable option, and the only family that runs unchanged on macOS and Windows, because it asks nothing of the kernel's packet path — it is an ordinary TCP service. It comes in two shapes. An explicit proxy listens on its own port and the client is pointed at it the standard way (an HTTPS_PROXY setting and the CONNECT method); the server is untouched. A reverse proxy binds 443 itself and forwards to an upstream you name, so the real service vacates 443 and moves behind it; here the client is untouched instead. So "proxy" never needs both a client and a server change — it needs exactly one, and you choose which.
The axis underneath the labels
Strip the names and there are really two engines and one question. The engines: a packet-rewriting engine (inline) and a socket-relay engine (everything else — redirect is just that engine fed by netfilter instead of by a client's proxy setting). The question is who holds the flow control. Anything built on kernel sockets — redirect, both proxies — gets the kernel's battle-tested TCP behavior at no cost. Inline gives that up to stay at the packet layer, and gets back the one property none of the others has: it touches nothing on either side. That single trade is the whole personality of the thing. Reach for inline when you can deploy on Linux and want zero footprint on the endpoints; reach for a socket transport when you need another operating system, can't install a kernel hook, or simply want the kernel to carry the bytes.
Same upgrade, three doorways
What none of this changes is the cryptography. Through any of the three, a classical client and a classical server can be joined onto an X25519MLKEM768 handshake (the key exchange of draft-ietf-tls-ecdhe-mlkem) without either of them learning a new cipher — the splice does the post-quantum part in the middle. The transport only decides the doorway: how visible you are, which OS you run on, and who, if anyone, edits a line of config. Choosing the right door for a given network is most of the migration work — and it is what we do for a living.