Got $50k spare? Then you can crack SHA-1 – so OpenSSH is deprecating flawed hashing algo in a 'near-future release'
(2020/05/28)
- Reference: 1590699791
- News link: https://www.theregister.co.uk/2020/05/28/openssh_deprecating_sha1/
- Source link:
The maintainers of OpenSSH, widely used 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 [1]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 [2]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 [3]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 cost [4]READ 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 [5]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 [6]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 [7]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 or it can't connect to an OpenSSH 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. ®
[1] https://eprint.iacr.org/2020/014.pdf
[2] https://sha-mbles.github.io/
[3] http://www.openssh.com/releasenotes.html
[4] https://www.theregister.co.uk/2020/01/08/hash_slamming_security_shamans/
[5] https://tools.ietf.org/html/rfc5656/
[6] http://blog.djm.net.au/2015/02/key-rotation-in-openssh-68.html
[7] https://twitter.com/marcan42/status/1265860482147082240
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 [1]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 [2]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 [3]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 cost [4]READ 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 [5]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 [6]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 [7]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 or it can't connect to an OpenSSH 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. ®
[1] https://eprint.iacr.org/2020/014.pdf
[2] https://sha-mbles.github.io/
[3] http://www.openssh.com/releasenotes.html
[4] https://www.theregister.co.uk/2020/01/08/hash_slamming_security_shamans/
[5] https://tools.ietf.org/html/rfc5656/
[6] http://blog.djm.net.au/2015/02/key-rotation-in-openssh-68.html
[7] https://twitter.com/marcan42/status/1265860482147082240
Old devices
Duncan Macdonald
Several older bits of equipment have firmware that can not be changed to support more secure protocols. These devices require SHA-1 . In many cases the cost of replacing the equipment would be prohibitive. (For example a controller that is part of an expensive industrial machine.)
A means of using SHA-1 still has to be available - and preferably NOT by disabling updates on a computer to keep the facility.
I used to work at NIST, which famously does a lot of security research and advised SHA-1 be disallowed. However, the IT teams inside NIST were often total dogshit, there was a lot of SHA-1 floating around on internal sites. In 2016 they started providing a new VDI service which allowed Linux users like me to access Windows on the occasions that we needed. The service was given a new SHA-1 cert. When I was unable to connect due to security policy the IT team happily gave me instructions on how to turn off disallowing SHA-1.
The only way forward is to just remove support!