Add support for QUIC and HTTP/3

[charescape]

Is there any plan to add support for HTTP/3 since it is now supported in all major browsers?

[gene1wood]

No, but PRs are welcome to add this.

[janbrasna]

The complicated part is not client support, but rather server support.

Nowadays it's still mostly experimental, behind forked modules, custom OpenSSL 3.2+QUIC builds etc. — so at the moment it's not a matter of a config flag to enable — it usually means some elbow grease to manually build your complete environment with the h3-enabled TLS stack in mind, often via BoringSSL or alternatives like QuicTLS. One of the main advantages of QUIC design is that it's not deeply tied to the host OSes and kernels and is mostly designed to live in the userspace to be more easily updated for new features etc., so there's a paradigm shift the traditional crypto/TLS provides can't seem to navigate effectively. It's slowly getting implemented at clients, APIs for servers are further down the roadmaps to stabilize… and we're barely out of draft revision and incompatibilities like when TLSv1.3 gradually made its way to final RFC version. Even cURL don't want to make any stability promises until any of the libraries needed exit experimental stage. Most products need to implement QUIC in a custom fashion to benefit from the likes of UDP connectionlessness, QPACK streams, 0-RTT, CID, BBR and other HTTP/3 changes so general use in server software without close ties to the actual application level is rather slow, and many wait for OpenSSL to build their own stack (since the way to just enable API integration from a few years ago hit a wall when OpenSSL clearly stated they won't integrate with existing QUIC stacks: openssl/openssl#8797 (comment) …)

Further reading to get the idea:

• https://curl.se/docs/http3.html
• https://www.nginx.com/blog/quic-http3-support-openssl-nginx/
• https://www.apachelounge.com/viewtopic.php?p=42277
• https://daniel.haxx.se/blog/2021/10/25/the-quic-api-openssl-will-not-provide/
• WIP: master QUIC support openssl/openssl#8797 (comment)
• HTTP/3 support haproxy/haproxy#680 (comment)
• Build HAProxy 2.6-dev with QUIC Support? docker-library/haproxy#182 (comment)
• https://github.com/haproxy/haproxy/blob/0c437b2dfc4841d1fa5013910af0932df6789d4f/INSTALL#L226
• https://github.com/haproxy/wiki/wiki/SSL-Libraries-Support-Status
• net/http: support HTTP/3 golang/go#32204 (comment)

From the perspective of @mozilla/ssl-config-generator or @mozilla/server-side-tls there's currently no need to tweak the TLS settings and turn configuration knobs, not unlike with TLSv1.3 "modern" config using basically the defaults, as it was designed to use only the better parts of the TLS world from "lessons learned". I don't think (and honestly only hope!) we won't need to fine tune any TLSv1.3 or HTTP/3 configuration outputs in the near future.
(And on the other hand adding the rulesets for protocols, APIs and ports and headers needed for h3 upgrades might be too specific to the stacks used with great variability right now, to provide one-liner config flags — we're probably not there yet either, if that's ever the scope of the config tool.)

Then, when you have some lovely h3 support like in Caddy, it's just there by default; nothing to configure. 🚀

[janbrasna]

@charescape TL;DR right now it's slightly painful to provide config lines for h3 upgrades when you need to compile experimental features hidden behind flags or in non-mainline binaries and link against alternative TLS implementations outside of main distros to get any meaningful QUIC support in the first place. 🤷

(I can imagine the h3 upgrade lines inactive behind # comments for sure, it's the documentation overhead needed to explain it just doesn't work out of the box that sounds like a nightmare to present to the generated config consumers right now.)