Weak cryptographic standards removal notice

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.