HTTPS Blocking Bypassed by HTTP/3 in a Branch

The traffic never enters the pipeline the profile was designed for.

• HTTP/3 runs over UDP 443 (QUIC), not TCP 443. The SSL/SSH profile in use is certificate-inspection, which only reads a certificate/SNI from a TCP TLS handshake; there is no such handshake in a QUIC flow to inspect.
• In flow-based mode the web filter needs that handshake to identify the site and assign a category. With no inspectable hostname, the session is logged as allowed/uncategorized.
• What is left is application control, which recognises the flow as QUIC. QUIC is not in the Peer-to-peer or Proxy category, so nothing blocks it. Anything the profile fails to identify falls to Unknown applications, which is set to Allow - the second half of the hole.
• Chrome's secure DNS removes the last hint: DNS-based categorisation and SNI lookups are no longer reliably visible.

Conclusion The profile is not failing; it is being routed around. Any control that depends on seeing the TLS handshake must either see the handshake or prevent the client from choosing a protocol that hides it.

Option A - force clients back to TCP TLS (recommended here)

• Add an application control entry that blocks QUIC/HTTP3, placed above any permissive entry, and/or add a deny policy above the internet policy for UDP 443 from the staff subnet.
• Clients fall back to TCP 443, where certificate inspection gives the web filter its category and the existing blocks take effect.
• Trade-off: QUIC's 0-RTT and loss-resilient behaviour disappear. On a lossy or high-latency WAN some SaaS apps feel slower and video start-up degrades. This must be tested with the business, not assumed harmless.
• Guardrails: never block TCP 443 when blocking UDP 443, or you break HTTPS entirely; confirm the app-control block is above the allow and that it logs, so you can see the fallback happening.

Option B - deep inspection for the population that needs it

• Full URL and file visibility, but requires distributing the FortiGate CA, breaks certificate-pinned applications, and is exactly what legal excluded.

Option C - accept HTTP/3 and rely on endpoint controls for the finance VLAN while Option A applies elsewhere.

Judgement for the CISO Option A is the only one that restores parity with the written policy without new endpoint trust. Present it with the measured performance delta from a one-week pilot on one floor, plus a note that Unknown applications should move from Allow to Block only after that pilot shows no false positives.

Prove the cause

• diagnose sniffer packet any 'udp port 443' 4 0 l on a test client's VLAN: see QUIC flowing from the workstation while the site is reachable.
• Compare with the application control log for the same minute: QUIC, action Allow.
• Have the same user load the site with HTTP/3 disabled in Chrome (chrome://flags) - it should now be blocked by the web filter with the right category. That single test distinguishes 'QUIC bypass' from 'category lookup broken'.

Verify the fix

• Re-run the sniffer: UDP 443 from the staff subnet should disappear or be reset, and TCP 443 should appear.
• Confirm the app-control log now shows QUIC blocked and the web-filter log shows the site denied with the correct category and the policy ID you expect.
• Run the block in monitor for 24–48 hours first, review the top applications by user and category, then convert to block. That avoids discovering a business-critical QUIC-only service after the fact.
• Re-check CPU and session counts after the change: every HTTP/3 session becomes a TCP session, which raises session counts and slightly increases inspection load.