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: Ryan Schmidt via curl-distros <curl-distros_at_lists.haxx.se>
Date: Tue, 26 Mar 2024 14:32:50 -0500
> On Mar 26, 2024, at 01:30, Billy O'Neal (VC AIR) 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.
I guess I didn't realize curl had the ability to select TLS backends at runtime! I wouldn't think most users would care what TLS backend is used as long as it works.
> I did some testing on several Linux distros and found that nobody seems to enable HTTP3 yet. How are other distros looking to resolve this problem, if at all?
Not a Linux package manager, but in MacPorts we let the user choose among the TLS backends at build time. MacPorts has a feature called variants which are user-selectable on/off switches that the portfile author can program to do anything. Often, a variant will add configure arguments and dependencies. And in the case of curl's TLS variants they're specified as conflicting with one another so that only one can be chosen.
MacPorts curl has many other variants, among them an http3 variant which is not on by default. If it is turned on, then it uses ngtcp2 and nghttp3. MacPorts ngtcp2 uses gnutls, therefore if the user asks for the curl http3 variant, they also automatically get the gnutls variant and cannot select another TLS backend. To date I have only received one complaint about this.
> On Mar 26, 2024, at 13:22, Billy O'Neal (VC AIR) wrote:
>
> We believe that customers want http3 more than they want multi TLS, so this situation doesn't
> *necessarily* need to change. What probably would need to change though before we would do that
> is that quic would need to work with the platform's defacto default TLS implementation
> (Secure Transport on macOS, schannel on Windows, OpenSSL on other).
>
> I have no idea where Secure Transport is on the quic question.
I don't represent Apple but my understanding is that they sunsetted Secure Transport many years ago. It is still in the OS so as not to break third party software that uses it, but it will not be enhanced to support http3 or any other new features. Software using Secure Transport is encouraged to adopt its successor, the Network framework. Last I heard nobody has volunteered to add code to curl to use Network framework.
Date: Tue, 26 Mar 2024 14:32:50 -0500
> On Mar 26, 2024, at 01:30, Billy O'Neal (VC AIR) 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.
I guess I didn't realize curl had the ability to select TLS backends at runtime! I wouldn't think most users would care what TLS backend is used as long as it works.
> I did some testing on several Linux distros and found that nobody seems to enable HTTP3 yet. How are other distros looking to resolve this problem, if at all?
Not a Linux package manager, but in MacPorts we let the user choose among the TLS backends at build time. MacPorts has a feature called variants which are user-selectable on/off switches that the portfile author can program to do anything. Often, a variant will add configure arguments and dependencies. And in the case of curl's TLS variants they're specified as conflicting with one another so that only one can be chosen.
MacPorts curl has many other variants, among them an http3 variant which is not on by default. If it is turned on, then it uses ngtcp2 and nghttp3. MacPorts ngtcp2 uses gnutls, therefore if the user asks for the curl http3 variant, they also automatically get the gnutls variant and cannot select another TLS backend. To date I have only received one complaint about this.
> On Mar 26, 2024, at 13:22, Billy O'Neal (VC AIR) wrote:
>
> We believe that customers want http3 more than they want multi TLS, so this situation doesn't
> *necessarily* need to change. What probably would need to change though before we would do that
> is that quic would need to work with the platform's defacto default TLS implementation
> (Secure Transport on macOS, schannel on Windows, OpenSSL on other).
>
> I have no idea where Secure Transport is on the quic question.
I don't represent Apple but my understanding is that they sunsetted Secure Transport many years ago. It is still in the OS so as not to break third party software that uses it, but it will not be enhanced to support http3 or any other new features. Software using Secure Transport is encouraged to adopt its successor, the Network framework. Last I heard nobody has volunteered to add code to curl to use Network framework.
-- curl-distros mailing list curl-distros_at_lists.haxx.se https://lists.haxx.se/mailman/listinfo/curl-distrosReceived on 2024-03-26