Last year we announced the deprecation of several weak cryptographic standards. We then provided a status update toward the end of last year outlining some changes we had made to make the transition easier for clients. We quickly approached the February 1, 2018 cutoff date noted in the prior posts, and as a result, have pushed back our schedule by one week. Starting on February 8, 2018 we will begin to disable the following:
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 will disable the algorithms in two stages:
- February 8, 2018 19:00 UTC (11:00 AM Pacific) – Disable deprecated algorithms for one hour.
- February 22, 2018 19:00 UTC (11:00 AM Pacific) – 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
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.
As always, if you have any questions or concerns related to this announcement, please don’t hesitate to contact us.