Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: How are folks handling HTTP3 TLS?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-distros <curl-distros_at_lists.haxx.se>
Date: Tue, 26 Mar 2024 08:35:38 +0100 (CET)
On Tue, 26 Mar 2024, Billy O'Neal (VC AIR) via curl-distros wrote:
> Unfortunately, trying to turn on HTTP3 disables curl's ability to select TLS
> backends at runtime, which would make a hypothetical HTTP3 feature mutually
> exclusive with all the other TLS backend features. Thus we are stuck in the
> unfortunate position of removing all the TLS backend features to add the
> HTTP3 feature, or refusing to add the HTTP3 feature for now.
(This does not really answer the question, but underscores the underlying
issues.)
In the curl project we have discussed two different takes that could
advance/change the situation. Both with their caveats and problems:
A) make the TLS runtime selection work also for HTTP/3. It could then allow
users to select for example Schannel but then HTTP/3 would not work (with the
ngtcp2 backend).
It would however still be problematic since the runtime selector cannot build
with multiple flavors of OpenSSL forks since that lead to symbol collisions.
So you could still not use vanilla OpenSSL for HTTP/2 and quictls for HTTP/3
for example.
B) make curl able to use two separate TLS libraries, one for QUIC and one for
TCP/TLS. That would allow the standard TLS runtime selection etc to work with
normal TCP/TLS and allow QUIC to use "something else".
But again, due to identical symbols the "somehing else" for QUIC could not
easily be an OpenSSL fork if one of those is used for TCP/TLS. Could still be
wolfSSL or GnuTLS of course.
Due to the inherent problems with both approaches, we have hesitated.
Unfortunately this means that this dilemma remains.
Date: Tue, 26 Mar 2024 08:35:38 +0100 (CET)
On Tue, 26 Mar 2024, Billy O'Neal (VC AIR) via curl-distros wrote:
> Unfortunately, trying to turn on HTTP3 disables curl's ability to select TLS
> backends at runtime, which would make a hypothetical HTTP3 feature mutually
> exclusive with all the other TLS backend features. Thus we are stuck in the
> unfortunate position of removing all the TLS backend features to add the
> HTTP3 feature, or refusing to add the HTTP3 feature for now.
(This does not really answer the question, but underscores the underlying
issues.)
In the curl project we have discussed two different takes that could
advance/change the situation. Both with their caveats and problems:
A) make the TLS runtime selection work also for HTTP/3. It could then allow
users to select for example Schannel but then HTTP/3 would not work (with the
ngtcp2 backend).
It would however still be problematic since the runtime selector cannot build
with multiple flavors of OpenSSL forks since that lead to symbol collisions.
So you could still not use vanilla OpenSSL for HTTP/2 and quictls for HTTP/3
for example.
B) make curl able to use two separate TLS libraries, one for QUIC and one for
TCP/TLS. That would allow the standard TLS runtime selection etc to work with
normal TCP/TLS and allow QUIC to use "something else".
But again, due to identical symbols the "somehing else" for QUIC could not
easily be an OpenSSL fork if one of those is used for TCP/TLS. Could still be
wolfSSL or GnuTLS of course.
Due to the inherent problems with both approaches, we have hesitated.
Unfortunately this means that this dilemma remains.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html
-- curl-distros mailing list curl-distros_at_lists.haxx.se https://lists.haxx.se/mailman/listinfo/curl-distrosReceived on 2024-03-26