Github停用TLS 1.0和TLS 1.1引起的血案

本想整理一下之前的笔记写成文章发上来，但是新项目赶着上线，各种奇葩问题频出，也就暂时搁置了。好不容易写了抽空写了一篇居然发不上来，deploy的时候老是提示SSL Exception啥的，于是搜了一下解决方案，大多数都是说要加大git的size，其实和git的size无关，这是由于Github最近停用了TLS 1.0和v 1.1导致的。

我们停用TLSv1/TLSv1.1啦

以下是原文

Last year we announced the deprecation of several weak cryptographic standards. Then we provided a status update toward the end of last year outlining some changes we’d made to make the transition easier for clients. We quickly approached the February 1, 2018 cutoff date we mentioned in previous posts and, as a result, pushed back our schedule by one week. On February 8, 2018 we’ll start disabling the following:

TLSv1/TLSv1.1: This applies to all HTTPS connections, including web, API, and git connections to https://github.com and https://api.github.com.
diffie-hellman-group1-sha1: This applies to all SSH connections to github.com
diffie-hellman-group14-sha1: This applies to all SSH connections to github.com
We’ll disable the algorithms in two stages:

February 8, 2018 19:00 UTC (11:00 am PST): Disable deprecated algorithms for one hour
February 22, 2018 19:00 UTC (11:00 am PST): Permanently disable deprecated algorithms
While only a small fraction of traffic currently makes use of the deprecated algorithms, and many clients will automatically transition and start using the new algorithms, there is invariably going to be a small fraction of clients that will be impacted. We expect most of these are older systems that are no longer maintained, but continue to access Git/the GitHub API using the deprecated algorithms. To help mitigate this, we will temporarily disable support for the deprecated algorithms for one hour on February 8, 2018 19::00 UTC. By disabling support for the deprecated algorithms for a small window, these systems will temporarily fail to connect to GitHub. We will then restore support for the deprecated algorithms and provide a two week grace period for these systems to upgrade their libraries before we disable support for the deprecated algorithms permanently on February 22, 2018.

Known incompatible clients
As noted above, the vast majority of traffic should be unaffected by this change. However, there are a few remaining clients that we anticipate will be affected. Fortunately, the majority of clients can be updated to work with TLSv1.2.

Git-Credential-Manager-for-Windows < v1.14.0
Git-Credential-Manager-for-Windows < v1.14.0 does not support TLSv1.2. This can be addressed by updating to v1.14.0.

Git on Red Hat 5, < 6.8, and < 7.2
Red Hat 5, 6, and 7 shipped with Git clients that did not support TLSv1.2. This can be addressed by updating to versions 6.8 and 7.2 (or greater) respectively. Unfortunately, Red Hat 5 does not have a point release that supports TLSv1.2. We advise that users of Red Hat 5 upgrade to a newer version of the operating system.

Java releases < JDK 8
As noted in this blog post by Oracle, TLSv1 was used by default for JDK releases prior to JDK 8. JDK 8 changed this behavior and defaults to TLSv1.2. Any client (ex. JGit is one such popular client) that runs on older versions of the JDK is affected. This can be addressed by updating to JDK >= 8 or explicitly opting in to TLSv1.2 in JDK 7 (look at the https.protocols JSSE tuning parameter). Unfortunately, versions of the JDK <= 6 do not support TLSv1.2. We advise users of JDK <= 6 to upgrade to a newer version of the JDK.

Visual Studio
Visual Studio ships with specific versions of Git for Windows and the Git Credential Manager for Windows (GCM). Microsoft has updated the latest versions of Visual Studio 2017 to work with TLSv1.2 Git servers. We advise users of Visual Studio to upgrade to the latest release by clicking on the in-product notification flag or by checking for an update directly from the IDE. Microsoft has provided additional guidance on the Visual Studio developer community support forum.

Conclusion
As always, if you have any questions or concerns related to this announcement, please don’t hesitate to contact us.