curl-library
Aw: Re: Question about CURLOPT_TLS13_CIPHERS
From: Bernhard Jaeger <B.Jaeger1_at_gmx.net>
Date: Thu, 2 Aug 2018 11:53:46 +0200
Date: Thu, 2 Aug 2018 11:53:46 +0200
Thank you for your answer.
I misunderstood the option.
> All libcurl options are documented since the version they are introduced! We
> even have tests that make sure we can't forget that.
> even have tests that make sure we can't forget that.
As a sidenote CURLOPT_TLS13_CIPHERS was already listed at https://curl.haxx.se/libcurl/c/curl_easy_setopt.html before the 7.61 release. The link just led to a 404 not found page.
-- Bernhard
Gesendet: Donnerstag, 02. August 2018 um 11:32 Uhr
Von: "Daniel Stenberg" <daniel@haxx.se>
An: "libcurl development" <curl-library@cool.haxx.se>
Betreff: Re: Question about CURLOPT_TLS13_CIPHERS
Von: "Daniel Stenberg" <daniel@haxx.se>
An: "libcurl development" <curl-library@cool.haxx.se>
Betreff: Re: Question about CURLOPT_TLS13_CIPHERS
On Thu, 2 Aug 2018, Bernhard Jaeger wrote:
> Until libcurl 7.60 the CURLOPT_TLS13_CIPHERS option was necessary to use TLS 1.3
> with libcurl.
No! CURLOPT_TLS13_CIPHERS was introduced in 7.61.0 (see
https://curl.haxx.se/changes.html#7_61_0). If you used it with a prior libcurl
version, it did nothing or would cause a compile time error (unless you used
a more recent header file).
CURLOPT_TLS13_CIPHERS is still not *necessary* - it is in fact rarely needed
at all but for exceptional cases where you need to control the TLS 1.3 ciphers
used.
> However the option was not documented so I assumed it was a boolean to toggle tls
> 13 on and I set the option like this:
>
> curl_easy_setopt(curl, CURLOPT_TLS13_CIPHERS, 1L);
All libcurl options are documented since the version they are introduced! We
even have tests that make sure we can't forget that.
> Which worked I could successfully establish a TLS 1.3 connection (with
> better Appconnect times than TLS 1.2)
This option doesn't enable/disable 1.3. Before 7.61.0, libcurl only required
that you explicitly allowed 1.3 to be used with CURLOPT_SSLVERSION. Since
7.61.0 that is not required anymore and libcurl is able to negotiate TLS 1.3
by default.
> Can somebody familiar with the libcurl code tell me what passing 1L as an
> argument does?
It might cause segfault if the pointer ends up used since something internally
will then try to get a string from that address and there's no string there.
But for 7.60.0 there's no code for CURLOPT_TLS13_CIPHERS so you could set it
to anything and libcurl wouldn't care (it would return an error in the
setopt() call though since the option is unknown).
> Documentation: " NULL, use internal default " What is the internal default?
That will then depend on the TLS library and how TLS 1.3 works. I don't
personally know this.
The point should be that the internal defaults are already sensible and made
to work with standard TLS 1.3 servers. You'd only poke with this option if you
know or suspect that the defaults aren't to your satisfaction.
--
/ daniel.haxx.se-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
> Until libcurl 7.60 the CURLOPT_TLS13_CIPHERS option was necessary to use TLS 1.3
> with libcurl.
No! CURLOPT_TLS13_CIPHERS was introduced in 7.61.0 (see
https://curl.haxx.se/changes.html#7_61_0). If you used it with a prior libcurl
version, it did nothing or would cause a compile time error (unless you used
a more recent header file).
CURLOPT_TLS13_CIPHERS is still not *necessary* - it is in fact rarely needed
at all but for exceptional cases where you need to control the TLS 1.3 ciphers
used.
> However the option was not documented so I assumed it was a boolean to toggle tls
> 13 on and I set the option like this:
>
> curl_easy_setopt(curl, CURLOPT_TLS13_CIPHERS, 1L);
All libcurl options are documented since the version they are introduced! We
even have tests that make sure we can't forget that.
> Which worked I could successfully establish a TLS 1.3 connection (with
> better Appconnect times than TLS 1.2)
This option doesn't enable/disable 1.3. Before 7.61.0, libcurl only required
that you explicitly allowed 1.3 to be used with CURLOPT_SSLVERSION. Since
7.61.0 that is not required anymore and libcurl is able to negotiate TLS 1.3
by default.
> Can somebody familiar with the libcurl code tell me what passing 1L as an
> argument does?
It might cause segfault if the pointer ends up used since something internally
will then try to get a string from that address and there's no string there.
But for 7.60.0 there's no code for CURLOPT_TLS13_CIPHERS so you could set it
to anything and libcurl wouldn't care (it would return an error in the
setopt() call though since the option is unknown).
> Documentation: " NULL, use internal default " What is the internal default?
That will then depend on the TLS library and how TLS 1.3 works. I don't
personally know this.
The point should be that the internal defaults are already sensible and made
to work with standard TLS 1.3 servers. You'd only poke with this option if you
know or suspect that the defaults aren't to your satisfaction.
--
/ daniel.haxx.se-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-08-02