The QUIC Problem

As I already mentioned a few times, most of network security today comes down to one simple rule: you can’t protect what you can’t see. Firewalls, DLP, IPS, all of it depends on somebody being able to look into the payload. And even that part isn’t fully solved already – I wrote before about how decryption on classic TCP/TLS traffic comes with its own baggage, certificate pinning breaks apps, performance, and I’ve seen decryption sign-off take months while the network side was ready in a week. Most organizations end up decrypting only part of their traffic or sometimes even nothing.

QUIC or HTTP/3 adoption keeps growing year over year, and it’s built on a transport most of the security stack still can’t touch at all.

With classic HTTPS over TCP, decryption is a well understood. The firewall sits in the middle, terminates the client’s TLS session, opens its own TLS session to the server, and re-encrypts everything in between. It works because TCP and TLS are two separate, well documented layers stacked on top of each other, and the handshake itself have enough metadata – SNI, cipher suite, certificate.

QUIC doesn’t give you that. It runs over UDP, and it doesn’t sit “on top” of TLS – it embeds the TLS 1.3 handshake directly inside its own transport. Almost everything past the first packet is encrypted, including packet numbers and most of the header fields security tools normally use to track a connection. What’s left in clear text is basically the connection ID and a couple of flags. You can see a QUIC connection exists. You can’t really see what’s happening inside of it, and building a transparent interception proxy for QUIC means reimplementing a full QUIC stack on both ends. Some vendors are experimenting with it already – Cisco added experimental QUIC decryption support to Secure Firewall.

Block QUIC

If you can’t decrypt QUIC, the only way to get visibility back is forcing the client off it entirely, back onto a transport you can actually decrypt. That’s why Palo Alto, Fortinet and basically everyone else in this space land on the exact same move: block QUIC and force fallback to plain TLS over TCP, where the existing decryption policy still applies.

Fallback

Blocking QUIC on the firewall should force the browser back onto TCP, and most of the time it does. But not always, and the reason sits in how HTTP/3 negotiation actually works. A server offering HTTP/3, and the browser caches that preference for a fixed period rather than checking it fresh on every request. Normally, if QUIC then fails, the browser retries over TCP and moves on quietly. But because the preference sits in cache instead of being reevaluated, I’ve seen it many times, on Edge – keep retrying QUIC on a domain that just failed a moment earlier, instead of switching to TLS. From the user side it just looks like “this one service is broken today” – tab hangs, page won’t load –  so it usually lands as a support ticket.

So where does this leave us? Right now, with HTTP/3 adoption still climbing and most vendors nowhere near proper QUIC decryption, blocking is really the only option . TLS 1.3 itself was painful for inspection tools when it landed, now it’s just the standard everybody built around, so I’d expect the same to eventually happen with QUIC.

And there’s one more reason not to treat this as a future problem. C2 frameworks added QUIC, as example Kaspersky documented QUIC RAT running its command and control traffic through HTTP/3. The blind spot isn’t theoretical. Threat actors already using it.