A business application moved to QUIC on UDP/443, and so did a channel you did not authorise — what are your options and what does each cost?

## Why a TCP-shaped stack goes quiet Most inspection positions were built around TCP: follow the handshake, reassemble the byte stream, hold per-connection state on a four-tuple, and if you must intervene, inject a reset. QUIC removes every one of those handholds. It runs over UDP, it does its own loss recovery and ordering inside an encrypted envelope, it multiplexes streams that a middlebox cannot see individually, and it has no cleartext control plane for anyone to inject into. A device that was doing useful work on the same application over TCP yesterday can be reduced to counting UDP datagrams today, without any configuration having changed. ## What is still readable — correct the wrong answer first "We can see nothing in QUIC" is the answer a competent senior engineer often gives, and it is wrong in a way that matters. QUIC's Initial packets are protected with keys derived from a value carried in the packet itself, precisely so that endpoints and middleboxes can process them before a shared secret exists. That means an on-path observer can parse the Initial and read the embedded TLS ClientHello — including `server_name` — exactly as it would over TCP, unless the client is using encrypted client hello. Version negotiation and connection identifiers are also visible. What is unavailable is everything after the handshake: packet numbers are protected, frames are encrypted, streams are invisible, and there is nothing to reassemble. So name-level policy survives the move to QUIC; payload-level policy does not. ## The three positions, and the bill on each **Deny outbound UDP/443.** This is the common first move and it works today for a specific reason: most clients treat QUIC as an optimisation and fall back to TCP when it fails, some after a delay. Your existing inspection then applies unchanged. The costs are real and they compound. Users on lossy or high-latency links lose the performance QUIC was giving them, sometimes noticeably on conferencing and media. Some services are QUIC-preferring to the point of degrading badly, and a growing number of newer transports do not fall back at all. You need a carve-out list for those, which is a second exemption list with the same ratchet as the first. And the whole mitigation decays: it depends on client vendors continuing to implement a fallback you are relying on but do not control. Turning it on is an enforcement event — pick a window, publish it, have a rollback, and make sure the person who owns the affected business application agreed beforehand. **Allow it unread.** Cheapest today and worst over time. The moment UDP/443 is the one path with no inspection behind it, it becomes the obvious transport for anything that wants to avoid you — an unauthorised tool, a data channel, or simply an application whose owner wanted to dodge a policy conversation. You have not just lost that traffic; you have advertised where the gap is. **Inspect QUIC properly.** Terminating or parsing QUIC at the border costs capacity — per-connection cryptographic state on a box previously sized for TCP flows — and it introduces a specific operational trap. QUIC identifies a connection by a connection ID, not by the address pair, so a client that changes network (or whose address translation rebinds) continues the same connection from a new source address. Anything you keyed on the five-tuple — a state table entry, a policy verdict, a session log correlation — sees two things where the endpoints see one. Your logs fragment and your state table fills with halves of connections. ## The fourth option, and its honest limit Moving inspection to where plaintext still exists — on the managed endpoint, or at the service you operate — sidesteps the transport question entirely, because you are reading before encryption or after decryption rather than in the middle. It is the direction the economics push toward as the readable share at the border falls. Its limit is coverage, and the limit is structural, not fixable with money: it covers devices you manage. Contractors, personal devices, printers, cameras, building systems and anything with a trust store you cannot alter are outside it by construction, and those are exactly the devices an intruder prefers. ## How to answer this in a loop A strong answer does four things in order: corrects the premise (the handshake is still readable, the payload is not); names the three border positions with a concrete cost on each; notes the connection-migration trap because it shows you have operated the thing rather than read about it; and finishes with the coverage limit of endpoint inspection rather than presenting it as the obvious answer. Whichever position you choose, say who signs for the outage on the day you enforce it — that sentence is what separates a design from a preference.