git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Daniel Carpenter <dc@ammonit.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: http.sslVersion only specifies minimum TLS version, later versions are allowed
Date: Mon, 03 May 2021 15:55:31 +0200	[thread overview]
Message-ID: <87pmy7x6le.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <8f664b07d1df45bcb6b3f787f42bd046@ammonit.com>


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...


  reply	other threads:[~2021-05-03 13:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-03 11:56 Daniel Carpenter
2021-05-03 13:55 ` Ævar Arnfjörð Bjarmason [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pmy7x6le.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=dc@ammonit.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this inbox:

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).