Interested in bringing GitHub Enterprise to your organization?
Start your free trial for 30 days and increase your team’s collaboration. $21 per user/month after trial expires.
Curious about other plans?
Hello again from Git Systems, the team at GitHub that makes sure your source code is available and secure. You may remember that we’ve recently made some changes to improve protocol security on GitHub.com. Now, we’re bringing these changes to GitHub Enterprise Server as well, starting with version 3.6.
We’re changing which algorithms and keys are supported in SSH and disabling the unencrypted Git protocol. Specifically, we are:
These changes will be included in GitHub Enterprise Server 3.6.
Only users connecting via SSH or
git:// are affected. If your Git remotes start with https://, nothing in this post will affect you. If you’re an SSH user, read on for the details and timeline.
Cryptography depends on secure algorithms and sufficiently strong keys to remain secure. “Fewer bits” generally means “easier to brute force,” and older algorithms have known attacks. What was considered secure in, say 2001, might no longer be acceptable today given changes in computing power, new attacks, and so on.
In this case, we’re moving away from DSA and SHA-1 to make sure that the algorithms we ship are secure and robust. Similarly, the unencrypted Git protocol doesn’t provide privacy, integrity, or authenticity, like the HTTPS and SSH protocols do. As of GHES 3.6, the unencrypted Git protocol is deprecated and defaults to off.
Most of the changes are the same. However, in this case, we’ve also made some of the changes configurable for GitHub Enterprise Server administrators who have different needs.
In all these cases, we’ve chosen to provide a secure default. We understand that this may be surprising or even disruptive in some environments, so we’ve balanced those defaults with options to maximize customizability.
In GitHub Enterprise Server 3.4 and newer, we’ve included a program called
ghe-find-insecure-git-operations. It will print out any log lines that indicate the use of an insecure algorithm, which you can then investigate. However, by default, it ignores log entries where we know that the client would automatically upgrade to a more secure algorithm once the insecure configuration is disabled, in order to avoid needless noise.
If you’re using OpenSSH 7.2p2 or later, PuTTY 0.75 or later, or a Go SSH client from March 15 or later, then you should be fine if you’re not using DSA client keys. In our testing, DSA client keys are very rare and have not been the default in any SSH client for well over a decade, so most people will have a different key type instead.
We expect most people using a recent version of OpenSSH from Git for Windows, macOS, or a Linux distribution released in the past five years should have no problems.
We’re always keeping an eye on the latest developments in security, attacks in the wild, and use of features in order to keep the GitHub community secure. We’ll continue to watch RSA with SHA-1 usage on GitHub.com and listen to GitHub Enterprise servers about their usage of the Git protocol. Once they decline, naturally, we’ll update the community on plans to fully deprecate these features.