Why does a URL filter blocking wetter.ch often fail in practice, and what does QUIC have to do with it?

Modern sites use HTTP/3 over QUIC (UDP), which encrypts most metadata inside the protocol — the FW can't see the hostname, so URL filtering doesn't trigger.

The classical setup:

• HTTPS = HTTP over TLS over TCP. The TLS handshake's SNI (Server Name Indication) leaks the hostname in plaintext early in the handshake → FW reads SNI → URL filter applies.

With QUIC (HTTP/3):

• Runs on UDP, encryption baked into the protocol from the very first packet.
• No plaintext SNI leakage in the same way — early packets are encrypted using keys derived in earlier sessions.
• FW sees encrypted UDP/443 traffic and shrugs.

Result: wetter.ch URL block does nothing; the user reaches the site over QUIC.

Mitigation (Palo Alto's recommendation):

• Block UDP/80 and UDP/443 at the FW.
• This forces browsers to fall back to HTTP/1.1 or HTTP/2 over TCP, where TLS-SNI inspection still works.
• Tradeoff: Lose QUIC's performance benefits (0-RTT, better mobile handoff, less head-of-line blocking).

Tip: "Block QUIC = re-enable visibility." It's an explicit "we sacrifice speed for security" decision.

Go deeper:

• A QUIC update on Google's experimental transport (Chromium Blog) — Google's own early write-up on QUIC's design and why it moves the crypto into UDP.