If I'm not mistaken, OpenSSL's implementation of the QUIC protocol has performance issues compared to QuicTLS.

If I'm not mistaken, OpenSSL's implementation of the QUIC protocol has performance issues compared to QuicTLS.

But isn't this using ngtcp2 for QUIC and only OpenSSL for crypto?
Or am I misunderstanding some of the build options?

But isn't this using ngtcp2 for QUIC and only OpenSSL for crypto?
Or am I misunderstanding some of the build options?

The ngtcp2 package supports OpenSSL 3.5 only through the libngtcp2_crypto_ossl helper library. I don't think this is full support.
I would prefer to use quictls in curl by default, but no one will agree to that - #179579

The ngtcp2 package supports OpenSSL 3.5 only through the libngtcp2_crypto_ossl helper library. I don't think this is full support.

According to both the documentation and what I have observed during builds, ngtcp2 uses a helper library for all cryptography libraries. It is true that quictls uses a different one (aptly called libngtcp2_crypto_quictls) and that the OpenSSL one has some extra requirements on its use that are documented there. However the only consumer of the quictls-using ngtcp2 in nixpkgs is curl, which documents building ngtcp2 against OpenSSL upstream without extra warnings, so I assume it is fine.

I would prefer to use quictls in curl by default, but no one will agree to that - #179579

For reasons that have only become better since then. The released quictls is unmaintained and had its last release 11 months ago, and OpenSSL in the meantime had several security-relevant changes such as vulnerability fixes and the introduction of ML-KEM support in 3.5 (for hybrid post-quantum key exchange support). Meanwhile the supposed replacement has no release at all yet, and with upstream OpenSSL improving their QUIC support the case for QuicTLS does not look to get more compelling.

Now Samba package with QUIC support based on ngtcp2 library has been released. Probably soon QUIC module for Linux kernel will be released. And none of them support OpenSSL's QUIC implementation.

If necessary, quictls can be replaced with wolfSSL, BoringSSL, aws-lc or libressl.

@Izorkin I'm not sure I understand what you are suggesting. This PR also uses ngtcp2 (and OpenSSL for crypto) for curl's http/3 support

This PR release changes the QUIC protocol implementation in ngtcp2 from OpenSSL 3.5, which is not supported by other projects. This may lead to bugs.

ngtcp2 + OpenSSL seems to be still marked as experimental, not sure if we actually want to ship this then
https://github.com/ngtcp2/ngtcp2/blob/2334b653df8a8ec9bafe6a1f2bf3ed30db6e9ef1/README.rst?plain=1#L69

Samba already builds against GnuTLS, so it would probably use ngtcp2-gnutls, in which case it doesn't matter at all what TLS library the main ngtcp2 package uses. I do not know about the kernel module, but would be very surprised if it depended at all on the ngtcp2 userspace library. Indeed I should have been clearer in the previous comment about the experimental status, however it is not so clear to me what to make of that given that curl (the only user of the ngtcp2 package) documents building ngtcp2 against OpenSSL without this disclaimer.

If necessary, quictls can be replaced with wolfSSL, BoringSSL, aws-lc or libressl.

From reading the curl configure.ac, It seems like these would require switching the main TLS library used by curl; it cannot use ngtcp2 + AWS‐LC for HTTP/3 while using OpenSSL for everything else, say.

So this would be a question of changing the default TLS library used by curl in general. GnuTLS we would rather get rid of as much as possible, LibreSSL lags behind OpenSSL these days, BoringSSL comes with no stability promises and is disclaimed by its upstream as unsuitable for general‐purpose use. The only palatable options would seem to be wolfSSL or AWS‐LC. AWS‐LC is in the OpenSSL fork family and already moderately load‐bearing for Rust stuff, so likely to be the most viable choice here.

Still, though, I am sceptical we would want to make that switch when we use OpenSSL so extensively anyway. curl and nghttp2 are the only consumers of our ngtcp2 package and curl seems to prefer the ngtcp2 + OpenSSL combination. It’s also the only option they’re giving CodeQL coverage in CI, for instance. I think the choice here is clear if we want to enable HTTP/3 support by default, which I think we do.

(After writing this, I see that it appears the CMake build of curl can support multiple TLS libraries, but it is explicitly not supported with HTTP/3. Even if it was, I’m not sure we’d want two of them in the closure with the attendant additional security exposure, and we don’t use the CMake build of curl anyway.)

Maybe then should create a separate package ngtcp2-openssl and use it?

And have no ngtcp2? It’s a bit awkward with by-name. OpenSSL is the TLS library we use as a default throughout the system, so it makes sense as a default here.

Maybe relevant question from curl maintainer Daniel Stenberg: https://curl.se/mail/lib-2025-10/0000.html

This does not appear relevant, as it relates to --enable-openssl-quic. Some other distributions use that but for nixpkgs you enabled ngtcp2.

Not related directly to this PR, yes, but to OpenSSL QUIC and curl

OpenSSL-QUIC support will be dropped in curl 8.19.0:
https://daniel.haxx.se/blog/2026/01/17/more-http-3-focus-one-backend-less/

Again, this is not relevant, because nixpkgs uses ngtcp2.