HTTP/3 (QUIC) for Nextcloud and Apache — Complete Guide

📑 How to
, , , ,
21

While this is an impressive documentation, the real questions may be, whether people actually want QUIC and allowed to use it …

No firewall admin I know about would ever allow QUIC, and for good reasons.

I completely breaks many aspects of a stateful firewall and reduces control massively.

For what? For some smaller benefits on mobile connections.

22

You’re right that QUIC changes how stateful firewalls work. Let’s look at what actually changes and what doesn’t.

What’s technically true: TCP gives firewalls a clean connection lifecycle — SYN, SYN-ACK, ACK, FIN. The firewall knows exactly when a connection starts and ends. With QUIC over UDP, there’s no such handshake. Firewalls have to use timeouts to track flows. Additionally, QUIC encrypts almost everything beyond the initial handshake — connection close signals, stream metadata, retry tokens. Deep Packet Inspection goes mostly blind. And Connection Migration (the same logical connection suddenly arriving from a different IP) looks like an unauthorized new flow to a traditional stateful firewall.

Daniel Stenberg anticipated this exact discussion in his book HTTP/3 Explained — “Will it be blocked?”. It’s worth reading.

But let’s be honest about what “breaks” actually means here. The firewall isn’t broken. It still sees source IP, destination IP, destination port, and packet sizes. It can still allow or block UDP/443 per host, per subnet, per policy. What it loses is the ability to deeply inspect the content of the traffic — which is another way of saying the traffic is better encrypted than before. Whether that’s a security problem or a security improvement depends on your perspective.

The resistance from firewall administrators is understandable but worth examining:

  • Expensive enterprise firewalls (Palo Alto, Fortinet, Check Point) have sold features built around TCP inspection and TLS interception. QUIC makes some of those features less effective. That’s a business model problem for the vendor, not necessarily a security problem for the organization.
  • “We’ve never allowed UDP/443” is a policy that made perfect sense five years ago. Today, over 30% of global web traffic runs on QUIC. Google, Cloudflare, Meta, and most major CDNs serve HTTP/3 by default. At some point, blocking a third of the internet’s transport protocol becomes a user experience problem that lands on someone’s desk.
  • The concern about “reduced control” often translates to “I can’t MITM my users’ traffic as easily.” In a zero-trust world, that argument is getting harder to make.

Mobile traffic has been the majority of global internet traffic for years now. Connection migration, resilience to packet loss, faster handshakes — these aren’t edge cases, they’re the default experience for most users. Dismissing that as “smaller benefits” is dismissing the primary way most people access the internet.

And here’s the part that makes this a non-argument in practice: the Alt-Svc mechanism is designed specifically for environments where UDP/443 is blocked. If a client can’t reach QUIC, the browser silently falls back to HTTP/2 over TCP. No error, no breakage, nothing to troubleshoot. Offering HTTP/3 costs nothing for clients that can’t use it. Blocking it costs something for clients that can.

ernolf

23

And by the way — in the hybrid setup described in the guide, every single QUIC request passes through Apache with ModSecurity and the full OWASP CRS ruleset before it reaches the application. SQL injection, XSS, path traversal, protocol violations — all inspected on every request, regardless of transport protocol. The inspection doesn’t disappear with QUIC, it moves from the network layer (where it was always limited) to the application layer (where it actually understands what it’s looking at). You end up with more security, not less: encrypted transport via QUIC on the wire, plus full WAF inspection on the server. :wink:

ernolf