【问题标题】：Git on Windows not working with remote because of "SSL protocol" errors由于“SSL 协议”错误，Windows 上的 Git 无法与远程一起使用
【发布时间】：2015-08-25 17:32:03
【问题描述】：

tl;博士

由于神秘的“SSL 协议”错误，Windows 上的 Git 停止连接到 github。哈！

问题

我正在 Windows 上进行开发，使用私有 GitHub 存储库进行源代码控制。当我第一次启动我的系统时，我可以毫无问题地访问远程仓库 - pull、push、fetch 等都可以正常工作。

一段时间后（*），这会停止，我收到以下错误：

致命：无法访问“https://github.com/our-team/private-repo.git/”：连接到 github.com:443 时出现未知 SSL 协议错误

(*) 时间的长短似乎是可变的 - 我目睹了短短一两个小时，长达一整天。一般从系统休眠回来后，好像是有问题，不知道是时间延迟还是系统休眠造成的。

通过 cURL 检查，我得到了

λ 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

将set GIT_CURL_VERBOSE=1 与git pull 一起使用会显示类似的信息。有时它会成功（见下文），但大多数时候它会失败。

补充说明

它有点零星的性质 - 有时我可以让请求成功，但一旦它开始爆炸，它通常会在 10 个请求中被破坏 9 个或更多。

成功的 cURL 请求如下所示：

λ 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

问题

我在谷歌上搜索了很多试图找到这个（在几个星期的过程中，所以我没有链接），但大多数建议似乎都指向证书错误或 OpenSSL 版本不匹配/错误（这将'不要像这样 AFAIK 那样零星）。

什么可能导致此故障，我该如何解决？

相关软件：

λ 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

【问题讨论】：

如果在命令行中使用重定向目标 url 会发生什么？ "卷曲 -v github.com/our-team/private-repo"
@jthill - 好主意！这似乎是相同的行为。大多数时候，cURL 调用都会失败。当它最终通过 SSL 握手成功时，它返回一个 404（这是预期的，因为它是一个私有存储库并且我没有通过 cURL 发送凭据）。所以症状似乎仍然存在。

标签： windows git curl github msysgit

【解决方案1】：

奇怪的是，问题在于笔记本电脑因电源不足而受到限制。我使用的扩展坞插入了低安培电源 (3.3 A)，虽然它与笔记本电脑兼容，但它立即将其踢入了节流模式。

显然，这会减慢一切，以至于 SSL 握手无法足够快地完成。

我们终于在阅读了讨论速度问题的戴尔支持论坛帖子 (http://en.community.dell.com/support-forums/laptop/f/3518/t/19363340) 后找到了它。解决方案是更换电源。

我也经历过这种缓慢，但我不认为这是相关的。我们为扩展坞更换了高安培电源，一切又恢复正常，上面描述的 SSL 错误也消失了。

【讨论】：

很好的反馈，比我的回答更准确。 +1
感谢您研究此问题。只是为了增加知识库，我在间歇性重负载的机器上遇到了同样的问题（我有几个虚拟机在后台运行）。有时 git push 命令失败（特别是如果我从 IntelliJ IDEA 中推送），有时它们会成功，但没有明显的原因。阅读您的解释后，我关闭了虚拟机，发现命令几乎一直都成功。您会认为可以实现更强大的 SSL 通信......

【解决方案2】：

这看起来像是一个错误，可能是在 Logjam attack -- weakdh.org -- 之后采取的安全措施造成的。
这导致了suppression of some ciphers accepted in a SSL/TLS transaction。

请注意，如“Cannot communicate securely with peer: no common encryption algorithm(s)”中所述，您将能够通过通过 git 将正确的密码列表传递给 curl。

在此之前，您还可以尝试在使用更新的适用于 Windows 的 Git 时问题是否仍然存在（例如 Git 2.4.1）

【讨论】：

【解决方案3】：

有同样的问题。禁用我的 wifi 连接并切换到电缆，一切都恢复正常。顺便说一句：在坞站中也使用了戴尔。

【讨论】：