All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Randall S. Becker" <rsbecker@nexbridge.com>
To: "'Jeff King'" <peff@peff.net>, "'Daniel Carpenter'" <dc@ammonit.com>
Cc: "'Ævar Arnfjörð Bjarmason'" <avarab@gmail.com>, git@vger.kernel.org
Subject: RE: http.sslVersion only specifies minimum TLS version, later versions are allowed
Date: Mon, 3 May 2021 17:01:32 -0400	[thread overview]
Message-ID: <000c01d7405f$823fd090$86bf71b0$@nexbridge.com> (raw)
In-Reply-To: <YJBhH0eLKRSpPFy3@coredump.intra.peff.net>

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


  parent reply	other threads:[~2021-05-03 21:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

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

  git send-email \
    --in-reply-to='000c01d7405f$823fd090$86bf71b0$@nexbridge.com' \
    --to=rsbecker@nexbridge.com \
    --cc=avarab@gmail.com \
    --cc=dc@ammonit.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.