The GitHub Security Lab examined the most popular open source software running on our home labs, with the aim of enhancing its security. Here's what we found and what you can do to better protect your own smart home.
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.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.
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 does not support
TLSv1.2. This can be addressed by updating to v1.14.0.
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.
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 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.
As always, if you have any questions or concerns related to this announcement, please don’t hesitate to contact us.