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