In the 18-May-2018 post by Jim Redmond (https://bitbucket.org/blog/deprecating-tlsv1-tlsv1-1-2018-12-01), the suggested command for checking the Git command line on UNIX-based systems doesn't work on my CentOS 7 vm.
Here is the published command line:
GIT_CURL_VERBOSE=1 git ls-remote https://bitbucket.org/
I get the following response when I attempt this:
[root@localhost ~]# GIT_CURL_VERBOSE=1 git ls-remote https://bitbucket.org/
* Couldn't find host bitbucket.org in the .netrc file; using defaults
* About to connect() to bitbucket.org port 443 (#0)
* Trying 18.205.93.1...
* Connected to bitbucket.org (18.205.93.1) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=bitbucket.org,OU=Bitbucket,O="Atlassian, Inc.",L=San Francisco,ST=California,C=US,serialNumber=3928449,incorporationState=Delaware,incorporationCountry=US,businessCategory=Private Organization
* start date: Apr 19 00:00:00 2018 GMT
* expire date: Apr 21 12:00:00 2020 GMT
* common name: bitbucket.org
* issuer: CN=DigiCert SHA2 Extended Validation Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US
> GET /info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/2.15.0
Host: bitbucket.org
Accept: */*
Accept-Encoding: gzip
Accept-Language: en-US, *;q=0.9
Pragma: no-cache
< HTTP/1.1 404 Not Found
< Cache-Control: max-age=900
< Content-Type: text/plain; charset=utf-8
< X-B3-Traceid: b1123df8a2b1c4d9d778e67eec4b2d30
< Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
< Date: Wed, 28 Nov 2018 17:52:07 GMT
< X-Server: 8b6c6c9a34f2
< X-Content-Type-Options: nosniff
< Connection: close
< X-Version: a8c3445ad7
< Content-Length: 31
<
* Closing connection 0
remote: Repository info/refs not found
fatal: repository 'https://bitbucket.org/' not found
This looks like an issue on the bitbucket side to me ("repository 'https://bitbucket.org/' not found"
Time is running short, is anybody from Atlassian paying attention?
Correction (and thank you to those who pointed this out): TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 is actually part of TLSv1.2 so in this case @ZeetixTom, you are not affected.
Hello @ZeetixTom,
I am looking at this paragraph from the referenced page:
The Git command line on UNIX-based systems (including macOS, Linux, and all BSDs) may be affected. You should be able to test your connection from the command line: GIT_CURL_VERBOSE=1 git ls-remote https://bitbucket.org/
This will connect to Bitbucket using the Git client and list the connection parameters. If you see a line like “SSL connection using TLSv1.2” in the output, then you are unaffected; if that line mentions a different version of TLS, then you are affected.
and I'm seeing this line in your output:
* SSL connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Which tells me that you are affected.
The "repository 'https://bitbucket.org/' not found" message is a red-herring. You are referencing a non-existent repo but that doesn't matter because what you're looking for has already been posted in the connection messages.
Hope this helps, if so, please remember to click the "Accept Answer" button so others see it has been in their search output. Thanks!
~~Larry Brock
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Interesting!
I'm still confused, though. According to sites like https://www.ibm.com/support/knowledgecenter/en/SS4T7T_2.4.3/com.ibm.help.seas.secure.doc/seas_supported_cipher_suites.html, the default cipher I have ("TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256") is part of "TLSv1.2".
Isn't that what I want?
I've checked the versions on my system, and I think I'm up to date:
openSSL:
[root@localhost ~]# openssl version
OpenSSL 1.0.2k-fips 26 Jan 2017
centos 7: [root@localhost ~]# lsb_release -d
Description: CentOS Linux release 7.4.1708 (Core)
I'm not sure how to best proceed here. Any guidance on what I needs to be updated or configured?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I answered elsewhere, but both GCM and SHA-256 (note: not just "SHA", needs to be either "SHA256" or "SHA384") are specific to TLSv1.2. I've also updated the blog post to mention that.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Jim and others have confirmed that the response I got indicates that I'm all set.
I've decided to hold off on accepting this answer because, as is, it conveys an impression that my system was susceptible to this issue when, in fact, it is not.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.