Jim D asked:
Starting today (or within the last few days) I’ve hit an SSL error when trying to connect to github.com (e.g. to clone a repository).
This is a legacy server running Red Hat 4.1.2-33.
Here’s what it looks like when I try to connect:
$ curl https://www.github.com --verbose * About to connect() to www.github.com port 443 (#0) * Trying 184.108.40.206... connected * Connected to www.github.com (220.127.116.11) port 443 (#0) * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * NSS error -12286 * Closing connection #0 * SSL connect error curl: (35) SSL connect error
I can see from this page that the NSS error code is:
“Cannot communicate securely with peer: no common encryption
The local and remote systems share no cipher suites in common. This
can be due to a misconfiguration at either end. It can be due to a
server being misconfigured to use a non-RSA certificate with the RSA
key exchange algorithm.
If I’m putting this altogether right, it appears that github.com has a recently updated SSL certificate and my server doesn’t have a cipher suite compatible with it. This is a legacy server so I’m not that surprised.
yum update nss (since that what curl seems to be using) as well as
yum update openssl but none of those packages have updated.
I’ve also tried following the procedure outline here but to no avail.
I’m sort of hitting a wall with my knowledge of how TLS handshakes work to even troubleshoot this much deeper. Does anyone have any good ideas on how to start digging deeper and figuring out what’s going wrong and where I need to update things? Upgrading the OS is for the time being not an option.
Digging further, it appears to be an issue with libcurl and the cipher it is using when connecting to github.com via git. I can get curl to work if I specify a compatible cipher explicitly:
$ curl https://github.com --cipher rsa_aes_128_sha
And I can even add the
--cipher rsa_aes_128_sha parameter to a .curlrc file and have curl use that cipher by default. Unfortunately, this doesn’t seem to get picked up by the git command so it got me nowhere…nor could I find an alternate way to specify the cipher. This is what the result of a verbose
git pull looks like on a github.com repository:
$ GIT_CURL_VERBOSE=1 git pull * Couldn't find host github.com in the .netrc file, using defaults * About to connect() to github.com port 443 (#0) * Trying 18.104.22.168... * Connected to github.com (22.214.171.124) port 443 (#0) * CAfile: /root/certs/cacert.pem CApath: none * NSS error -12286 * Expire cleared * Closing connection #0 * Couldn't find host github.com in the .netrc file, using defaults * About to connect() to github.com port 443 (#0) * Trying 126.96.36.199... * Connected to github.com (188.8.131.52) port 443 (#0) * CAfile: /root/certs/cacert.pem CApath: none * NSS error -12286 * Expire cleared * Closing connection #0 error: SSL connect error while accessing https://github.com/twbs/bootstrap.git/info/refs fatal: HTTP request failed
This might be a dead-end…looks like this guy on StackOverflow ran into the exact same issue.
SSL/TLS configuration today is driven by security considerations which have arisen in the past couple of years such as the BEAST and CRIME attacks, and the weakness of RC4, and which — in some cases — will result in some old clients being unable to communicate at all, since they don’t support more modern protocols, cipher suites, etc. Even RHEL 5 clients occasionally have trouble communicating with RHEL 6 servers via SSL/TLS. With some work, you may be able to manually specify a cipher suite to use, but it’s highly unlikely with something as old as RHEL4. This state of affairs makes upgrading your only real option.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.