4

tl;dr

Git on Windows stops connecting to github because of mysterious "SSL protocol" errors. Halp!

The Issue

I'm developing on Windows, using a private GitHub repo for source control. When I first boot my system, I'm able to access the remote repo without issue - pull, push, fetch, etc. all work just fine.

After some amount of time(*), this stops, and I get the following error:

fatal: unable to access 'https://github.com/our-team/private-repo.git/': Unknown SSL protocol error in connection to github.com:443

(*) The amount of time seems variable - I've witnessed as little as an hour or two, up to a whole day. Usually after coming back from the system sleeping, it seems to be an issue, but I don't know if it's caused by a time delay or by the system sleeping.

Checking via cURL, I get

λ curl -v "https://github.com/our-team/private-repo.git/" * Trying 192.30.252.130... * Connected to github.com (192.30.252.130) port 443 (#0) * successfully set certificate verify locations: * CAfile: C:\Program Files (x86)\Git\bin\curl-ca-bundle.crt CApath: none * TLSv1.0, TLS handshake, Client hello (1): * Unknown SSL protocol error in connection to github.com:443 * Closing connection 0 curl: (35) Unknown SSL protocol error in connection to github.com:443

Using set GIT_CURL_VERBOSE=1 with git pull shows similar information. Sometimes it succeeds (see below), but most of the time it fails.

Further Notes

There's a little bit of a sporadic nature to it - sometimes I can get requests to succeed, but once it starts exploding, it's generally broken 9 out of 10 requests or more.

A successful cURL request looks like:

λ curl -v "https://github.com/our-team/private-repo.git/" * Trying 192.30.252.130... * Connected to github.com (192.30.252.130) port 443 (#0) * successfully set certificate verify locations: * CAfile: C:\Program Files (x86)\Git\bin\curl-ca-bundle.crt CApath: none * TLSv1.0, TLS handshake, Client hello (1): * TLSv1.0, TLS handshake, Server hello (2): * TLSv1.0, TLS handshake, CERT (11): * TLSv1.0, TLS handshake, Server finished (14): * TLSv1.0, TLS handshake, Client key exchange (16): * TLSv1.0, TLS change cipher, Client hello (1): * TLSv1.0, TLS handshake, Finished (20): * TLSv1.0, TLS change cipher, Client hello (1): * TLSv1.0, TLS handshake, Finished (20): * SSL connection using TLSv1.0 / AES128-SHA * Server certificate: * subject: businessCategory=Private Organization; 1.3.6.1.4.1.311.60.2.1.3=US; 1.3.6.1.4.1.311.60.2.1.2=Delaware; serialNumber=5157550; street=548 4th Street; postalCode=94107; C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=github.com * start date: 2014-04-08 00:00:00 GMT * expire date: 2016-04-12 12:00:00 GMT * subjectAltName: github.com matched * issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 Extended Validation Server CA * SSL certificate verify ok. > GET /our-team/private-repo.git/ HTTP/1.1 > User-Agent: curl/7.41.0 > Host: github.com > Accept: */* > < HTTP/1.1 301 Moved Permanently < Server: GitHub.com < Date: Mon, 11 May 2015 15:19:43 GMT < Content-Type: text/html < Content-Length: 178 < Location: https://github.com/our-team/private-repo/ < Vary: Accept-Encoding < X-Served-By: 76f8aa18dab86a06db6e70a0421dc28c < <html> <head><title>301 Moved Permanently</title></head> <body bgcolor="white"> <center><h1>301 Moved Permanently</h1></center> <hr><center>nginx</center> </body> </html> * Connection #0 to host github.com left intact

The Question

I've googled a good bit on trying to find this (over the course of several weeks, so I don't have links), but most suggestions seem to point at certificate errors or OpenSSL version mismatches / bugs (which wouldn't be sporadic like this AFAIK).

What might be causing this failure, and how can I resolve it?

Relevant Software:

λ git --version git version 1.9.5.msysgit.1 λ curl --version curl 7.41.0 (i386-pc-win32) libcurl/7.41.0 OpenSSL/0.9.8zf zlib/1.2.8 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz
Improve this question
2
  • What happens if you use the redirect target url on the command line? "curl -v github.com/our-team/private-repo" Commented May 11, 2015 at 16:09
  • @jthill - good thought! It seemed to be much the same behavior. Most of the time, the cURL calls fail. When it finally succeeds with the SSL handshake, it returns a 404 (which is expected, since it's a private repo and I'm not sending credentials via cURL). So the symptoms seem to remain. Commented May 11, 2015 at 18:04

3 Answers 3

Reset to default
5

Oddly, it turns out that the issue is that the laptop was throttled because of a weak power supply. The docking station I was using was plugged into a low-amp powersupply (3.3 A), which, while it was compatible with the laptop, immediately kicked it into a heavily-throttled mode.

Apparently, this slowed everything down enough that the SSL handshake wasn't able to complete fast enough.

We finally tracked it down after reading a Dell support forum post (http://en.community.dell.com/support-forums/laptop/f/3518/t/19363340) that discussed slowness issues. The solution there was to change the power supply.

I had also experienced this slowness, but I did not think it was related. We swapped to a high-amp power supply for the dock, and everything was fine again, and the SSL errors described above went away.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Good feedback, more precise than my answer. +1
Thanks for researching this issue. Just to add to the knowledge base, I was experiencing the same problems on a machine that had intermittent heavy load (I had a couple of virtual machines running the in background). Sometimes git push commands were failing (particularly if I was pushing from within IntelliJ IDEA), sometimes they were succeeding, but there was no obvious reason as to why. After reading your explanation, I shutdown the VMs and discovered that the commands succeeded nearly all the time. You would have thought that more robust SSL comms could be implemented...
3

That looks like an error which could result from the security initiatives taken after the Logjam attack -- weakdh.org --.
That resulted in the suppression of some ciphers accepted in a SSL/TLS transaction.

Note that, as reported in "Cannot communicate securely with peer: no common encryption algorithm(s)", you will be able to pass the right cipher list to curl via git.

Before that, you can also try if the issue persists while using a more recent Git for Windows (like the Git 2.4.1)

Improve this answer

Comments

0

Had the same issue. Disabled my wifi connection and switched to cable and everything works again. Btw: Used a Dell in Docking-Station too.

Improve this answer

1 Comment

Here I am seven years later with a Dell laptop with exactly the same problem. On battery and wifi, I get this error. Docked with power and a wired network connection and no error.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.