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…
![](https://github.blog/wp-content/uploads/2021/04/Blog_ENGINEERING_for-social.png?resize=1200%2C630)
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.comdiffie-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.
Written by
Related posts
![](https://github.blog/wp-content/uploads/2023/10/Collaboration-DarkMode-2.png?resize=400%2C212)
2024 is the biggest global election year in history. What’s at stake for developers?
GitHub is considering what is at stake for our users and platform, how we can take responsible action to support free and fair elections, and how developers contribute to resilient democratic processes.
![](https://github.blog/wp-content/uploads/2023/10/AI-DarkMode-2.png?resize=400%2C212)
GitHub named a Leader in the Gartner first-ever Magic Quadrant for AI Code Assistants
This year, as part of its annual Magic Quadrant series, Gartner published a first-of-its-kind report analyzing the state of play in the AI Code Assistants market–and named GitHub a Leader.
![AI in software development 2024 survey results with colorful graphics and percentages.](https://github.blog/wp-content/uploads/2024/08/ai-survey-header.png?resize=400%2C212)
Survey: The AI wave continues to grow on software development teams
We surveyed 2,000 people on software development teams at enterprises in the U.S., Brazil, India, and Germany about the use, experience, and expectations around generative AI tools in software development.