Configure: MultiSSL cannot be enabled with HTTP/3 and vice versa

[Kangie]

We've recently enabled quic by default in Gentoo "testing" ebuilds. As we provide a mechanism for users to enable MultiSSL there are a number who choose to enable alternative TLS backends in order to meet thier requirements.

While I can provide package-manager flags to prevent this configuration from being enabled, it's also worth raising an issue to discuss.

I did this

./configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --datarootdir=/usr/share --disable-dependency-tracking --disable-silent-rules --disable-static --docdir=/usr/share/doc/curl-8.9.0 --htmldir=/usr/share/doc/curl-8.9.0/html --with-sysroot=/ --libdir=/usr/lib --without-ca-fallback --with-ca-bundle=/etc/ssl/certs/ca-certificates.crt --without-gnutls --without-mbedtls --without-rustls --with-gnutls --with-ssl --with-ca-path=/etc/ssl/certs --with-default-ssl-backend=openssl --enable-alt-svc --enable-basic-auth --enable-bearer-auth --enable-digest-auth --enable-kerberos-auth --enable-negotiate-auth --enable-aws --enable-dict --disable-ech --enable-file --enable-ftp --disable-gopher --enable-hsts --enable-http --enable-imap --disable-ldap --disable-ldaps --enable-ntlm --enable-pop3 --enable-rt --enable-rtsp --enable-smb --with-libssh2 --enable-smtp --disable-telnet --enable-tftp --enable-tls-srp --enable-ares --enable-cookies --enable-dateparse --enable-dnsshuffle --enable-doh --enable-symbol-hiding --enable-http-auth --enable-ipv6 --enable-largefile --enable-manual --enable-mime --enable-netrc --enable-progress-meter --enable-proxy --enable-socketpair --disable-sspi --disable-static --enable-pthreads --enable-threaded-resolver --disable-versioned-symbols --without-amissl --without-bearssl --without-brotli --with-fish-functions-dir=/usr/share/fish/vendor_completions.d --with-nghttp2 --without-hyper --with-libidn2 --with-gssapi=/usr --without-libgsasl --with-libpsl --without-msh3 --with-nghttp3 --without-ngtcp2 --with-openssl-quic --without-quiche --with-librtmp --without-schannel --without-secure-transport --without-test-caddy --without-test-httpd --without-test-nghttpx --enable-websockets --without-winidn --without-wolfssl --with-zlib --with-zstd --with-zsh-functions-dir=/usr/share/zsh/site-functions
. . .
configure: error: MultiSSL cannot be enabled with HTTP/3 and vice versa

I expected the following

Uncertain; worth discussing:

• Is this explicitly unsupported?
• Is there a reason to support MultiSSL + HTTP3/QUIC?
• What might that look like if so?

curl/libcurl version

curl 8.9.0

operating system

Gentoo Linux

[bagder]

With the MultiSSL feature, libcurl can get built to support multiple TLS backends, and to use a specific one selected from the set at startup. An original driving factor for this feature was to allow Schannel with other TLS backends on Windows so that users could access "native" CA certs in the Windows CA store. Subsequently, curl has introduced support in multiple TLS backends to use native CAs. This reduces the need for many people to use and switch TLS backends. There are probably also other use cases, since the TLS backends are not all alike.

The QUIC/h3 backends use TLS themselves but this code has not been adapted for multissl, which makes builds that enable HTTP/3 incompatible with the multissl option. For now, multissl and QUIC support are mutually exclusive in curl. This can of course be fixed, but it might not be trivial depending on the different QUIC solution(s) used and their requirements on the TLS libraries. Maybe we should just defer supporting this combo until A) someone brings a solid use case for it and B) someone wants to work on it.