Improving Git protocol security on GitHub Enterprise Server

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.

What’s changing?

We’re changing which algorithms and keys are supported in SSH and disabling the unencrypted Git protocol. Specifically, we are:

• Removing support for all DSA keys
• Adding requirements for newly-added RSA keys
• Removing the HMAC-SHA-1 algorithm
• Allowing administrators to enable Ed25519 host keys
• Turning off the unencrypted Git protocol

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.

Why are we making these changes?

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.

How is this different from the changes that have been made to GitHub.com?

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.

• First, administrators can configure the cut-off date for RSA keys using SHA-1, which defaults to midnight August 1, 2022, UTC. Keys uploaded after that date (or a date that they’ve chosen) will need to use RSA with SHA-2. Administrators can also choose to disable all use of RSA with SHA-1, if their environment is ready for that.
• While Ed25519 keys will be advertised automatically with OpenSSH-style host key rotation, administrators will need to specifically enable the use of the Ed25519 key for production use to avoid host key warnings on certain non-OpenSSH software.
• Finally, the unencrypted Git protocol will be disabled by default, but can be re-enabled by the administrator, if they’d like to do that.

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.

How do I verify that I’m ready?

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.

What’s next?

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.

Written by

Brian Carlson

@bk2204