Updated The maintainers of OpenSSH, the widely used toolkit for connecting securely to servers and devices over networks, have warned that the SHA-1 algorithm will be disabled in a "near-future release".
SHA stands for Secure Hash Algorithm. The SHA-1 implementation has been known to be vulnerable since 2005 though still requiring reassuringly non-trivial amounts of computation to break. More powerful attacks have been developed since, and compute resources have become cheaper, so the vulnerability gradually increases.
The OpenSSH decision references a recent paper [PDF] by Gaëtan Leurent and Thomas Peyrin, titled "SHA-1 is a Shambles," showing that a "chosen-prefix collision" can be achieved for $45,000 – more than a casual amount, but "within the means of academic researchers."
A chosen-prefix collision means it's possible to modify data – be it a file or information in transit – in such a way that both the previous and tampered versions have the same SHA-1 hash value. Thus, security checks relying on verifying data integrity from SHA-1 hashes can be fooled.
"It is now possible to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. For this reason, we will be disabling the 'ssh-rsa' public key signature algorithm by default in a near-future release," said OpenSSH maintainer Damien Miller in the release notes for OpenSSH 8.3, echoing similar comments from the 8.2 release notes back in February.
Hash snag: Security shamans shame SHA-1 standard, confirm crucial collisions citing circa $45k chip costREAD MORE
The OpenSSH team suggest users and administrators use alternative, more secure hashing algorithms including SHA-2 (supported since OpenSSH 7.2 four years ago) or the even older ssh-ed25519 or ECDSA (Elliptic Curve Digital Signature Algorithm) as proposed in 2009. Another suggestion is to use the UpdateHostKeys setting in OpenSSH clients, which automatically updates the client's knowledge of the keys identifying the server and the algorithm used, as explained by Miller here in 2015.
These statements have caused some confusion concerning matters such as whether keys will have to be regenerated, and what will happen with hardware tokens or network devices with out-of-date firmware. It is important to distinguish between keys and hash algorithms.
"OpenSSH's advisory was worded very confusingly, but the way it works is that ssh-rsa *keys* can be used with both the ssh-rsa *algorithm* and the rsa-sha2-256 *algorithm*. If both sides support the latter then there is no SHA-1 in use," said security consultant Hector Martin on Twitter.
Removal of SHA-1 support in OpenSSH will still be significant. "This algorithm is unfortunately still used widely despite the existence of better alternatives," said Miller, and it seems that actually removing support is the only way to prevent its use.
Essentially, if a device or client can support something better than SHA-1 that's also supported by OpenSSH, all will be well; if it's hardwired to SHA-1, action is needed to connect to an OpenSSH server that no longer supports the algorithm.
Alan Woodward, professor of cybersecurity at the University of Surrey in England, told The Register that "SHA-1 is no longer secure but actually it is still fairly difficult to crack," which is true, but equally the fact that it has been known to be flawed for over a decade and remains in wide use shows how slow the industry is to move.
The cost of cracking SHA-1 will continue to fall, so now is the time to stop using it. ®
Updated to add
We asked Miller for clarification of the impact of removing SHA-1 support.
“A ssh-rsa key does not need to be regenerated to be useful with the updated signature algorithms," he told us. "Specifically, an existing ssh-rsa key is perfectly usable with the rsa-sha2-256 or rsa-sha2-512 algorithms.”
What about old devices that use SHA-1? “We're talking about changing the default set of enabled algorithms and not removing ssh-rsa support entirely (at least not yet). So no devices will be completely unusable, at worst they will require an extra command-line argument or a couple of lines of configuration. There are some examples of this at openssh.com/legacy.html.
"Devices that do not support the RFC8332 RSA/SHA-2 signature methods, and do not support any of the other, more modern key types, will need that extra step. Otherwise ssh will refuse to connect. These more-modern key types that I mentioned include the ECDSA keys defined in RFC5656 that was published over ten years ago. If users' devices are newer than this then I think it's quite legitimate for them to ask their vendors why they weren't shipping modern cryptography in their products.”