Discontinue support for weak cryptographic standards
Cryptographic standards are ever evolving. It is the canonical game of security cat and mouse, with attacks rendering older standards ill-suited, and driving the community to develop newer and stronger…
Cryptographic standards are ever evolving. It is the canonical game of security cat and mouse, with attacks rendering older standards ill-suited, and driving the community to develop newer and stronger standards to take their place. There have been a number of cryptographic attacks over the past of couple of years. These include, but are not limited to, attacks such as POODLE and Logjam . And, while there have been workarounds for some of these attacks, they demonstrated that several cryptographic standards in wide deployment are showing their age and should be retired. As a result, GitHub is announcing the immediate deprecation, and eventual disablement, of our use of the following cryptographic standards:
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.
All of the above will be disabled on February 1, 2018.
In order to minimize the number of users affected by this change we intend do the following before disabling support:
- Post quarterly updates to the GitHub engineering and GitHub developer blogs to remind people of the deprecation and encourage them to prepare for the change.
- Reach out to popular projects that we know to be currently incompatible with these changes.
- Update our own SSH implementation to add support for
diffie-hellman-group-exchange-sha256
, as this will minimize the number of SSH clients affected.
Technical details
TLS 1/1.1
The vast majority of HTTPS connections (approximately 95%) made to https://github.com and https://api.github.com use TLS 1.2 and will not be affected. This includes every currently shipping browser used by GitHub users. The vast majority of connections made to GitHub services using TLS 1/TLS 1.1 are clients built using older SSL/TLS libraries that do not support TLS 1.2. Mostly commonly, this includes clients built using older versions of the Java JDK as well clients built on operating systems bundled with an older version of OpenSSL.
The Java JDK did not use TLS 1.2 by default until JDK 8 was released in 2014. While JDK 7 supported TLS 1.2, it was not enabled by default for compatibility reasons. Likewise, OpenSSL did not support TLS 1.2 until version 1.0.1 was released in 2012. As a result, several popular older operating systems, such as Red Hat 5, continue to rely on older versions of OpenSSL. We appreciate the difficulty associated with upgrading systems that rely on these older libraries, but feel the security gained for all GitHub users make it a worthwhile trade-off.
Weak SSH key exchange algorithms
GitHub supports both HTTPS as well as SSH based connections when performing Git operations. When a SSH connection is made to github.com, the client and server must determine a mutually agreeable set of cryptographic algorithms to use for the connection. One such algorithm is the key exchange algorithm. The key exchange algorithm is used to securely exchange a strong cryptographic key to protect future messages in the protocol. Without a secure key exchange algorithm, all future messages exchanged between the client and server can’t be trusted.
The Logjam Attack research released in 2015 noted some key exchange algorithms were subject to an attack and should be disabled. In particular, they encouraged all system administrators to disable support for the diffie-hellman-group1-sha1
key exchange algorithm. While their analysis further clarified that diffie-hellman-group14-sha1
should be secure for the foreseeable future, GitHub is choosing to pro-actively discontinue support for this algorithm as well. SSH supports a number of more contemporary algorithms that are not subject, even theoretically, to the precompuation attacks described in the Logjam research.
The majority of SSH connections (approximately 75% ) made to GitHub.com are compatible with more contemporary SSH key exchange algorithms and will not be affected by the removal of diffie-hellman-group1-sha1
and diffie-hellman-group14-sha1
. However, that leaves a minority, but still substantial, set of clients that are currently only compatible with one of the legacy key exchange algorithms. Fortunately, the vast majority of these clients do support some newer algorithms, but none that currently overlap with those supported by GitHub. As a result, GitHub will add support for diffie-hellman-group-exchange-sha256
before we remove support for diffie-hellman-group1-sha1
and diffie-hellman-group14-sha1
. By adding support for diffie-hellman-group-exchange-sha256
we estimate that 5% of current clients would be affected.
Conclusion
We understand that this will incur additional burden for a small set of developers and users. It is for that reason that we are announcing this deprecation now. We hope that, given approximately a year to prepare, developers and users are able to upgrade their operating systems, libraries, and client software to be compatible with these changes. If you have any questions or concerns related to this announcement, please don’t hesitate to contact us.
Written by
Related posts
Unlocking the power of unstructured data with RAG
Unstructured data holds valuable information about codebases, organizational best practices, and customer feedback. Here are some ways you can leverage it with RAG, or retrieval-augmented generation.
GitHub Availability Report: May 2024
In May, we experienced one incident that resulted in degraded performance across GitHub services.
How we improved push processing on GitHub
Pushing code to GitHub is one of the most fundamental interactions that developers have with GitHub every day. Read how we have significantly improved the ability of our monolith to correctly and fully process pushes from our users.