git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* http.sslVersion only specifies minimum TLS version, later versions are allowed
@ 2021-05-03 11:56 Daniel Carpenter
  2021-05-03 13:55 ` Ævar Arnfjörð Bjarmason
  0 siblings, 1 reply; 9+ messages in thread
From: Daniel Carpenter @ 2021-05-03 11:56 UTC (permalink / raw)
  To: git

When I run: "GIT_SSL_VERSION=tlsv1.2 GIT_CURL_VERBOSE=T git clone https://github.com/git/git.git"

I see: "SSL connection using TLS1.3 / ECDHE_RSA_AES_128_GCM_SHA256", but I was expecting to see "TLS1.2".

This happens because the "sslversions" array ( https://github.com/git/git/blob/7e391989789db82983665667013a46eabc6fc570/http.c#L58 ) uses "CURL_SSLVERSION_TLSv1_2" which only specifies TLS 1.2 or later ( https://curl.se/libcurl/c/CURLOPT_SSLVERSION.html ).

I think configuring "tlsv1.2" should imply "CURL_SSLVERSION_TLSv1_2 | CURL_SSLVERSION_MAX_TLSv1_2", to force that specific version (and the same for "tlsv1.0", "tlsv1.1", "tlsv1.3").

For background: I noticed this because of this issue with debian buster https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987188 . The new libcurl backport enables TLS 1.3 support with gnutls, but it doesn't work for certain operations, so buster applications using a backported libcurl need to explicitly disable TLS 1.3 .

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: http.sslVersion only specifies minimum TLS version, later versions are allowed
  2021-05-03 11:56 http.sslVersion only specifies minimum TLS version, later versions are allowed Daniel Carpenter
@ 2021-05-03 13:55 ` Ævar Arnfjörð Bjarmason
  2021-05-03 14:10   ` Jeff King
  0 siblings, 1 reply; 9+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2021-05-03 13:55 UTC (permalink / raw)
  To: Daniel Carpenter; +Cc: git


On Mon, May 03 2021, Daniel Carpenter wrote:

> When I run: "GIT_SSL_VERSION=tlsv1.2 GIT_CURL_VERBOSE=T git clone https://github.com/git/git.git"
>
> I see: "SSL connection using TLS1.3 / ECDHE_RSA_AES_128_GCM_SHA256", but I was expecting to see "TLS1.2".
>
> This happens because the "sslversions" array (
> https://github.com/git/git/blob/7e391989789db82983665667013a46eabc6fc570/http.c#L58
> ) uses "CURL_SSLVERSION_TLSv1_2" which only specifies TLS 1.2 or later
> ( https://curl.se/libcurl/c/CURLOPT_SSLVERSION.html ).
>
> I think configuring "tlsv1.2" should imply "CURL_SSLVERSION_TLSv1_2 |
> CURL_SSLVERSION_MAX_TLSv1_2", to force that specific version (and the
> same for "tlsv1.0", "tlsv1.1", "tlsv1.3").
>
> For background: I noticed this because of this issue with debian
> buster https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987188 . The
> new libcurl backport enables TLS 1.3 support with gnutls, but it
> doesn't work for certain operations, so buster applications using a
> backported libcurl need to explicitly disable TLS 1.3 .

I think you're right per the documentation, but I wonder if the current
behavior isn't more useful for most users. I.e. are there really users
who want exactly 1.2 and not 1.3, 1.4 etc. in the future that aren't
dealing with an issue like what you're encountering?

I.e. the "better security in the future by default" seems like a
better/more common case than "pin to this forever" in this case, no?

We should of course have a way to pin it, but given the current behavior
I wonder if we shouldn't just change the documentation, and introduce
support for e.g. "=tlsv1.1" etc, or a http.pinSSLVersion=tls1.1 or
something...


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: http.sslVersion only specifies minimum TLS version, later versions are allowed
  2021-05-03 13:55 ` Ævar Arnfjörð Bjarmason
@ 2021-05-03 14:10   ` Jeff King
  2021-05-03 15:02     ` Daniel Carpenter
  0 siblings, 1 reply; 9+ messages in thread
From: Jeff King @ 2021-05-03 14:10 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason; +Cc: Daniel Carpenter, git

On Mon, May 03, 2021 at 03:55:31PM +0200, Ævar Arnfjörð Bjarmason wrote:

> On Mon, May 03 2021, Daniel Carpenter wrote:
> 
> > When I run: "GIT_SSL_VERSION=tlsv1.2 GIT_CURL_VERBOSE=T git clone https://github.com/git/git.git"
> >
> > I see: "SSL connection using TLS1.3 / ECDHE_RSA_AES_128_GCM_SHA256", but I was expecting to see "TLS1.2".
> >
> > This happens because the "sslversions" array (
> > https://github.com/git/git/blob/7e391989789db82983665667013a46eabc6fc570/http.c#L58
> > ) uses "CURL_SSLVERSION_TLSv1_2" which only specifies TLS 1.2 or later
> > ( https://curl.se/libcurl/c/CURLOPT_SSLVERSION.html ).
> >
> > I think configuring "tlsv1.2" should imply "CURL_SSLVERSION_TLSv1_2 |
> > CURL_SSLVERSION_MAX_TLSv1_2", to force that specific version (and the
> > same for "tlsv1.0", "tlsv1.1", "tlsv1.3").
> >
> > For background: I noticed this because of this issue with debian
> > buster https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987188 . The
> > new libcurl backport enables TLS 1.3 support with gnutls, but it
> > doesn't work for certain operations, so buster applications using a
> > backported libcurl need to explicitly disable TLS 1.3 .
> 
> I think you're right per the documentation, but I wonder if the current
> behavior isn't more useful for most users. I.e. are there really users
> who want exactly 1.2 and not 1.3, 1.4 etc. in the future that aren't
> dealing with an issue like what you're encountering?
> 
> I.e. the "better security in the future by default" seems like a
> better/more common case than "pin to this forever" in this case, no?
> 
> We should of course have a way to pin it, but given the current behavior
> I wonder if we shouldn't just change the documentation, and introduce
> support for e.g. "=tlsv1.1" etc, or a http.pinSSLVersion=tls1.1 or
> something...

Just looking at how the curl binary does it, "--tlsv1.2" means "1.2 or
greater" (which is not at all surprising; the library interface tends to
mirror their command-line and vice versa, and our behavior is influenced
by the library interface here).  But that implies to me that curl folks
considered this and though the "or greater" behavior was useful (which
makes sense -- the main goal is probably to avoid insecurities in older
versions of the protocol).

Anyway, the binary also has --tls-max for capping the maximum version.
That seems more flexible in general than "use this version exactly" (if
you only care that 1.3 is broken, then setting "max=1.2" lets you talk
to servers that support 1.1 or 1.2).

-Peff

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: http.sslVersion only specifies minimum TLS version, later versions are allowed
  2021-05-03 14:10   ` Jeff King
@ 2021-05-03 15:02     ` Daniel Carpenter
  2021-05-03 20:46       ` Jeff King
  0 siblings, 1 reply; 9+ messages in thread
From: Daniel Carpenter @ 2021-05-03 15:02 UTC (permalink / raw)
  To: Jeff King, Ævar Arnfjörð Bjarmason; +Cc: git

> On Mon, May 03, 2021 at 03:55:31PM +0200, Ævar Arnfjörð Bjarmason wrote:
> 
> > On Mon, May 03 2021, Daniel Carpenter wrote:
> >
> > > When I run: "GIT_SSL_VERSION=tlsv1.2 GIT_CURL_VERBOSE=T git clone https://github.com/git/git.git"
> > >
> > > I see: "SSL connection using TLS1.3 / ECDHE_RSA_AES_128_GCM_SHA256", but I was expecting to see "TLS1.2".
> >
> > I think you're right per the documentation, but I wonder if the current
> > behavior isn't more useful for most users. I.e. are there really users
> > who want exactly 1.2 and not 1.3, 1.4 etc. in the future that aren't
> > dealing with an issue like what you're encountering?
> >
> > I.e. the "better security in the future by default" seems like a
> > better/more common case than "pin to this forever" in this case, no?
> >
> > We should of course have a way to pin it, but given the current behavior
> > I wonder if we shouldn't just change the documentation, and introduce
> > support for e.g. "=tlsv1.1" etc, or a http.pinSSLVersion=tls1.1 or
> > something...
> 
> Just looking at how the curl binary does it, "--tlsv1.2" means "1.2 or
> greater" (which is not at all surprising; the library interface tends to
> mirror their command-line and vice versa, and our behavior is influenced
> by the library interface here).  But that implies to me that curl folks
> considered this and though the "or greater" behavior was useful (which
> makes sense -- the main goal is probably to avoid insecurities in older
> versions of the protocol).
> 
> Anyway, the binary also has --tls-max for capping the maximum version.
> That seems more flexible in general than "use this version exactly" (if
> you only care that 1.3 is broken, then setting "max=1.2" lets you talk
> to servers that support 1.1 or 1.2).
> 
> -Peff

I agree that the current behaviour is better for most users, and that some kind of separate "max" config option would work for anyone in my situation.

Another idea would be to keep the current behaviour for `http.sslVersion`, but use an exact match with the environment variable only. That already takes priority, and I imagine its main appeal over the config option is for users that want to try something with a specific TLS version.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: http.sslVersion only specifies minimum TLS version, later versions are allowed
  2021-05-03 15:02     ` Daniel Carpenter
@ 2021-05-03 20:46       ` Jeff King
  2021-05-03 20:56         ` Daniel Stenberg
  2021-05-03 21:01         ` Randall S. Becker
  0 siblings, 2 replies; 9+ messages in thread
From: Jeff King @ 2021-05-03 20:46 UTC (permalink / raw)
  To: Daniel Carpenter; +Cc: Ævar Arnfjörð Bjarmason, git

On Mon, May 03, 2021 at 03:02:10PM +0000, Daniel Carpenter wrote:

> > Just looking at how the curl binary does it, "--tlsv1.2" means "1.2 or
> > greater" (which is not at all surprising; the library interface tends to
> > mirror their command-line and vice versa, and our behavior is influenced
> > by the library interface here).  But that implies to me that curl folks
> > considered this and though the "or greater" behavior was useful (which
> > makes sense -- the main goal is probably to avoid insecurities in older
> > versions of the protocol).
> > 
> > Anyway, the binary also has --tls-max for capping the maximum version.
> > That seems more flexible in general than "use this version exactly" (if
> > you only care that 1.3 is broken, then setting "max=1.2" lets you talk
> > to servers that support 1.1 or 1.2).
> > 
> > -Peff
> 
> I agree that the current behaviour is better for most users, and that
> some kind of separate "max" config option would work for anyone in my
> situation.
> 
> Another idea would be to keep the current behaviour for
> `http.sslVersion`, but use an exact match with the environment
> variable only. That already takes priority, and I imagine its main
> appeal over the config option is for users that want to try something
> with a specific TLS version.

I think you're right that it may work for many people, but I'd shy away
from it simply because it's subtle and hard to explain.

Adding config and environment variables for "max" is pretty
straight-forward to explain. I think it would also make sense to improve
the documentation for http.sslVersion to make it clear that this is a
minimum (the current wording is quite misleading).

-Peff

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: http.sslVersion only specifies minimum TLS version, later versions are allowed
  2021-05-03 20:46       ` Jeff King
@ 2021-05-03 20:56         ` Daniel Stenberg
  2021-05-03 21:01         ` Randall S. Becker
  1 sibling, 0 replies; 9+ messages in thread
From: Daniel Stenberg @ 2021-05-03 20:56 UTC (permalink / raw)
  To: Jeff King; +Cc: Daniel Carpenter, Ævar Arnfjörð Bjarmason, git

On Mon, 3 May 2021, Jeff King wrote:

> I think it would also make sense to improve the documentation for 
> http.sslVersion to make it clear that this is a minimum (the current wording 
> is quite misleading).

While improving the http.sslVersion, maybe also consider dropping the special 
mention of NSS and OpenSSL in there? Maybe just like this:

         The SSL version to use when negotiating an SSL connection, if you
         want to force the default.  The available and default version
-       depend on whether libcurl was built against NSS or OpenSSL and the
-       particular configuration of the crypto library in use. Internally
+       depend on which TLS library libcurl was built to use. Internally
         this sets the 'CURLOPT_SSL_VERSION' option; see the libcurl
         documentation for more details on the format of this option and
         for the ssl version supported. Currently the possible values of

Maybe also consider dropping 'sslv2' and 'sslv3' from the docs now since 
virtually no TLS library supports them since several years now (as they're 
considered insecure and bad) and therefor asking curl to use those will more 
often than not rather cause an error.

-- 

  / daniel.haxx.se

^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: http.sslVersion only specifies minimum TLS version, later versions are allowed
  2021-05-03 20:46       ` Jeff King
  2021-05-03 20:56         ` Daniel Stenberg
@ 2021-05-03 21:01         ` Randall S. Becker
  2021-05-03 21:09           ` Daniel Stenberg
  1 sibling, 1 reply; 9+ messages in thread
From: Randall S. Becker @ 2021-05-03 21:01 UTC (permalink / raw)
  To: 'Jeff King', 'Daniel Carpenter'
  Cc: 'Ævar Arnfjörð Bjarmason', git

On May 3, 2021 4:46 PM, Jeff King wrote:
>On Mon, May 03, 2021 at 03:02:10PM +0000, Daniel Carpenter wrote:
>
>> > Just looking at how the curl binary does it, "--tlsv1.2" means "1.2
>> > or greater" (which is not at all surprising; the library interface
>> > tends to mirror their command-line and vice versa, and our behavior
>> > is influenced by the library interface here).  But that implies to
>> > me that curl folks considered this and though the "or greater"
>> > behavior was useful (which makes sense -- the main goal is probably
>> > to avoid insecurities in older versions of the protocol).
>> >
>> > Anyway, the binary also has --tls-max for capping the maximum version.
>> > That seems more flexible in general than "use this version exactly"
>> > (if you only care that 1.3 is broken, then setting "max=1.2" lets
>> > you talk to servers that support 1.1 or 1.2).
>> >
>> > -Peff
>>
>> I agree that the current behaviour is better for most users, and that
>> some kind of separate "max" config option would work for anyone in my
>> situation.
>>
>> Another idea would be to keep the current behaviour for
>> `http.sslVersion`, but use an exact match with the environment
>> variable only. That already takes priority, and I imagine its main
>> appeal over the config option is for users that want to try something
>> with a specific TLS version.
>
>I think you're right that it may work for many people, but I'd shy away from it
>simply because it's subtle and hard to explain.
>
>Adding config and environment variables for "max" is pretty straight-forward to
>explain. I think it would also make sense to improve the documentation for
>http.sslVersion to make it clear that this is a minimum (the current wording is
>quite misleading).

What if http.sslVersion=v1[,v2]... were supported, so there would be an enumeration of allowed versions. The benefit of an enumeration is that you could force something like 3.0-fips if your environment requires a FIPS-certified version for communication. Admittedly this is a different use case than discussed above.

Just a thought.

Randall


^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: http.sslVersion only specifies minimum TLS version, later versions are allowed
  2021-05-03 21:01         ` Randall S. Becker
@ 2021-05-03 21:09           ` Daniel Stenberg
  2021-05-03 21:23             ` Randall S. Becker
  0 siblings, 1 reply; 9+ messages in thread
From: Daniel Stenberg @ 2021-05-03 21:09 UTC (permalink / raw)
  To: Randall S. Becker
  Cc: 'Jeff King', 'Daniel Carpenter',
	'Ævar Arnfjörð Bjarmason',
	git

On Mon, 3 May 2021, Randall S. Becker wrote:

> What if http.sslVersion=v1[,v2]... were supported, so there would be an 
> enumeration of allowed versions.

That doesn't map very well to the options libcurl provide.

> The benefit of an enumeration is that you could force something like 
> 3.0-fips if your environment requires a FIPS-certified version for 
> communication. Admittedly this is a different use case than discussed above.

Yes, and as "3.0-fips" is not a TLS version at all I think it would complicate 
matters in a wrong direction.

You can build libcurl to use use a FIPS compatible crypto library today, but 
if you do then you still select TLS version using the same options like 
before.

-- 

  / daniel.haxx.se

^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: http.sslVersion only specifies minimum TLS version, later versions are allowed
  2021-05-03 21:09           ` Daniel Stenberg
@ 2021-05-03 21:23             ` Randall S. Becker
  0 siblings, 0 replies; 9+ messages in thread
From: Randall S. Becker @ 2021-05-03 21:23 UTC (permalink / raw)
  To: 'Daniel Stenberg'
  Cc: 'Jeff King', 'Daniel Carpenter',
	'Ævar Arnfjörð Bjarmason',
	git

On May 3, 2021 5:10 PM, Daniel Stenberg wrote:
>Subject: RE: http.sslVersion only specifies minimum TLS version, later
versions
>are allowed
>
>On Mon, 3 May 2021, Randall S. Becker wrote:
>
>> What if http.sslVersion=v1[,v2]... were supported, so there would be
>> an enumeration of allowed versions.
>
>That doesn't map very well to the options libcurl provide.
>
>> The benefit of an enumeration is that you could force something like
>> 3.0-fips if your environment requires a FIPS-certified version for
>> communication. Admittedly this is a different use case than discussed
above.
>
>Yes, and as "3.0-fips" is not a TLS version at all I think it would
complicate
>matters in a wrong direction.
>
>You can build libcurl to use use a FIPS compatible crypto library today,
but if you
>do then you still select TLS version using the same options like before.

Sadly, curl_version_info_data.ssl_version does not provide this level of
detail. Maybe it should, but I'm not about to go there.

Regards,
Randall


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-05-03 21:23 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-03 11:56 http.sslVersion only specifies minimum TLS version, later versions are allowed Daniel Carpenter
2021-05-03 13:55 ` Ævar Arnfjörð Bjarmason
2021-05-03 14:10   ` Jeff King
2021-05-03 15:02     ` Daniel Carpenter
2021-05-03 20:46       ` Jeff King
2021-05-03 20:56         ` Daniel Stenberg
2021-05-03 21:01         ` Randall S. Becker
2021-05-03 21:09           ` Daniel Stenberg
2021-05-03 21:23             ` Randall S. Becker

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://7fh6tueqddpjyxjmgtdiueylzoqt6pt7hec3pukyptlmohoowvhde4yd.onion/inbox.comp.version-control.git
	nntp://ie5yzdi7fg72h7s4sdcztq5evakq23rdt33mfyfcddc5u3ndnw24ogqd.onion/inbox.comp.version-control.git
	nntp://4uok3hntl7oi7b4uf4rtfwefqeexfzil2w6kgk2jn5z2f764irre7byd.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git