12 ms·

Dangerous SHA-1 crypto function is about to die in SSH

67 points by headalgorithm 6y ago

upofadown 6y ago
>The unanimous agreement among experts is that it's no longer safe in almost all security contexts. Except for the great many security contexts where chosen-prefix collisions are not problematic. NIST for example has suggested SHA-1 is acceptable for such applications ("Hash (B)") for "2019 - 2030 & beyond". * https://www.keylength.com/en/4/ https://www.keylength.com/en/4/
- goalieca 6y ago
  Another example is the mask generation function for rsa-oaep.
- zaarn 6y ago
  The german BSI does not recommend SHA1 and NIST only recommends it for 128bit security applications. And knowing if your application is not vulnerable to prefix attacks can be a bit of a challenge, depending on what you do. If you have to ask yourself what to use, you probably shouldn't be starting to use SHA1. If your application supports it, then you're good to go for "2020 - 2030 & beyond", otherwise I'd just go with SHA256/SHA3-256 or even SHA512/SHA3-512.
  - upofadown 6y ago
    From the 2020 BSI report: >From a security-technical perspective, however, there is, according to present knowledge,no reason speaking against using it in constructions which do not require collision resistance...
    - zaarn 6y ago
      Just because there is no reason against using something doesn't mean it's a good idea. They recommend SHA256 and upwards, they see no reason that SHA1 must be removed immediately from some corners of cryptography, those are no conflicting viewpoints. Just don't use SHA1 unless you absolutely are forced to do so, not when you make something new from scratch that can use SHA256.
      - upofadown 6y ago
        For all we know using SHA-1 where collisions are not an issue is a good idea. This sort of question has already came up for MD5 used where collisions were not an issue. Everyone spent a lot of time, money and compatibility moving away from MD5. We were told to move to SHA-1 which is now broken in the same way. It was pointless effort caused by pointless hysteria. Now we have pointless SHA-1 hysteria...
        zaarn 6y ago
        Maybe stop hardcoding cryptoalgo's so you have to spend a lot of money to migrate? This is why protocols like TLS support negotiations.
- kd913 6y ago
  Sorry but why exactly should NIST be trusted? https://projectbullrun.org/dual-ec/vulnerability.html https://projectbullrun.org/dual-ec/vulnerability.html It seems from many sources that NIST were pushing a backdoored RNG source for a while. The main source for the ssh-keys arch wiki even says not to trust NIST. https://wiki.archlinux.org/index.php/SSH_keys https://wiki.archlinux.org/index.php/SSH_keys https://stribika.github.io/2015/01/04/secure-secure-shell.html https://stribika.github.io/2015/01/04/secure-secure-shell.ht...
usr1106 6y ago
Good that arstechnica clearly explains that SHA-1 is the problem here. The protocol in question is called ssh-rsa, which easily leads to the misunderstanding that RSA keys would be deprecated. If I as a non-cryptographer understood it correctly the keys can remain, but different fingerprints are needed. Is it so that you have fingerprints in known_hosts, but not in authorized_keys?
- mkj 6y ago
  The authorized_keys file will not change. ssh-rsa as a key format will stay (it isn't specific to sha1 or sha2), just the client and server need to upgrade to sign/verify session-specific signatures using sha256 instead of sha1. rsasign(sha1(sessiondata)) becomes rsasign(sha256(sessiondata)). OpenSSH CA certificates are more urgent to upgrade since those are/were long lived sha1 signatures - sha1 there got disabled a couple of releases ago I think. The article seems bit sensational and lacking understanding.
- usr1106 6y ago
  There are no fingerprints in authorized_keys. I should have looked into the file before speculating. So no updates to the file needed.
grizzles 6y ago
We need a new default hash algorithm for general purpose stuff, because sha512 is a bit too long for copy/paste imho. I propose shac = sha1sum(sha512sum(data)) - for sha concatenated. Thoughts?
- tpetry 6y ago
  Sha2 is designed to be truncated to the length you want to have
- woodruffw 6y ago
  It's probably better to just truncate your SHA-2/512 (or any other SHA-2 variant) output to 160 bits (and add a tag, to avoid confusing people). That being said, most people are probably willing to live with the 8 additional bytes required by SHA-2/224 (which, IIRC, is itself a truncated special case of SHA-2/256).
  - grizzles 6y ago
    Good feedback. Thanks tpetry as well. I agree about the tag. It's a cultural oversight that all secure hashes aren't labelled as such. When one is used it ought to be identified by its respective hash algorithm, eg. sha1://7d157d7c000ae27db146575c08ce30df893d3a64
    - Dylan16807 6y ago
      It rarely matters, and that's not an insignificant amount of overhead, especially because you're putting those wasteful slashes in https://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address-mistake.html https://www.dailymail.co.uk/sciencetech/article-1220286/Sir-...
    - sneak 6y ago
      Are you familiar with multihash (which is used extensively in ipfs)? It’s an open standard and library and does exactly this (though the prefix tag itself is not human readable unless you are weird like us). I use it in my projects when I need to serialize hashes, as it has nice go and javascript libraries.
fortran77 6y ago
> Theoretically, the digests are supposed to be unique for every file, message, or other input fed into the function Given that the digests are shorter than the messages they are meant to identify, this is not at all a "theoretical" possibility (you can prove this with a "pigeonhole" proof).
- dasnab 6y ago
  I think they meant that the input should be unique for every two inputs actually fed into the function. That is, there are many, many collisions, but they won't ever be found in our lifetime.
rwmj 6y ago
One of the things we do at Red Hat is migrate virtual machines off RHEL 5-era Xen to modern KVM, and one of the problems we have is that you can no longer ssh into a RHEL 5 machine from a RHEL 8 machine because there's no common set of cyphers available. Currently you can work around this by relaxing the RHEL 8 machine's crypto policy to include "legacy"[1], although I wonder how long that option will be available. For reference RHEL 5 was released in 2007 and is supported to the end of this year for some customers. [1] http://libguestfs.org/virt-v2v-input-xen.1.html#ssh-authentication http://libguestfs.org/virt-v2v-input-xen.1.html#ssh-authenti...
- wlll 6y ago
  If I was running Redhat machines and had bought support to the end of the year I think I'd expect Redhat to release packages for RHEL 5 that let me SSH to them from RHEL 8 machines.
  - quietbritishjim 6y ago
    Doesn't it defeat the object of using an old, stable edition of an operating system if you keep installing feature updates to it?
    - rwmj 6y ago
      Red Hat does update RHEL with new features, although not RHEL 5 which is now only getting security fixes. In this case there is a workaround (on the RHEL 8 / ssh client end) which is to enable legacy crypto policies. However you have to do this globally at least for all ssh connections (and our recommended command does it globally for the whole machine), and I guess there are reasons why the legacy policies are disabled by default, probably to do with possible MITM attacks against weak cyphers. So the situation isn't exactly ideal. Having said all that it would be up to me to actually fix this and I haven't looked into it in great detail since I don't believe any customers have asked about it. We only found out about it in our internal product QA.
      - 6y ago
knorker 6y ago
So if ssh-rsa is going away, does that mean millions of smart card second factors will be bricked? Or since it's not RSA being taken out, is this just a matter of updating .authorized_keys with new SHA256 hashes for the same keys?
- tialaramex 6y ago
  Neither. The smart card just makes RSA signatures over input data, and an updated SSH client will use SHA256 rather than SHA-1, as input data so nothing changes for the smart card. The Authorized Keys list is of actual public keys, not hashes, so that doesn't change. That's why the line length is much longer for a larger key (e.g. 4096-bit RSA) and shorter for small key like ECDSA.
  - knorker 6y ago
    Doh, of course. Think-o on my part. Thanks. So in what sense is "ssh-rsa" going to be removed? Just as a protocol enum, with no user-visible impact for these purposes?
    - tialaramex 6y ago
      Both future clients and servers will refuse to do this algorithm, so it becomes user visible if your clients are not new enough to know anything acceptable to your servers or vice versa. The ssh-rsa algorithm is one of two authentication algorithms described in the first SecSH (IETF standardised SSH version 2) documents in 2006. The other (ssh-dsa) was never very popular and has been untrustworthy for a long time. So up until this point even a very old client or server could expect to interoperate with the latest software using ssh-rsa. Of course an individual setup might forbid this, but in general it could work. The announced change in OpenSSH means it will be necessary to give up on very old systems because they're incompatible, or else use a shim to restore compatibility if that's essential for you. This previously happened with SSH version 1 - once upon a time OpenSSH could interoperate with SSHv1, then it required a config override to allow that, and then they removed the compatibility from their source code entirely, but SSHv1 pre-dates the widespread modern popularity of SSH, so it probably had less impact than this will.

67 points by headalgorithm 6y ago

>The unanimous agreement among experts is that it's no longer safe in almost all security contexts. Except for the great many security contexts where chosen-prefix collisions are not problematic. NIST for example has suggested SHA-1 is acceptable for such applications ("Hash (B)") for "2019 - 2030 & beyond". * https://www.keylength.com/en/4/ https://www.keylength.com/en/4/

goalieca 6y ago
Another example is the mask generation function for rsa-oaep.
zaarn 6y ago
The german BSI does not recommend SHA1 and NIST only recommends it for 128bit security applications. And knowing if your application is not vulnerable to prefix attacks can be a bit of a challenge, depending on what you do. If you have to ask yourself what to use, you probably shouldn't be starting to use SHA1. If your application supports it, then you're good to go for "2020 - 2030 & beyond", otherwise I'd just go with SHA256/SHA3-256 or even SHA512/SHA3-512.
- upofadown 6y ago
  From the 2020 BSI report: >From a security-technical perspective, however, there is, according to present knowledge,no reason speaking against using it in constructions which do not require collision resistance...
  - zaarn 6y ago
    Just because there is no reason against using something doesn't mean it's a good idea. They recommend SHA256 and upwards, they see no reason that SHA1 must be removed immediately from some corners of cryptography, those are no conflicting viewpoints. Just don't use SHA1 unless you absolutely are forced to do so, not when you make something new from scratch that can use SHA256.
    - upofadown 6y ago
      For all we know using SHA-1 where collisions are not an issue is a good idea. This sort of question has already came up for MD5 used where collisions were not an issue. Everyone spent a lot of time, money and compatibility moving away from MD5. We were told to move to SHA-1 which is now broken in the same way. It was pointless effort caused by pointless hysteria. Now we have pointless SHA-1 hysteria...
      - zaarn 6y ago
        Maybe stop hardcoding cryptoalgo's so you have to spend a lot of money to migrate? This is why protocols like TLS support negotiations.
kd913 6y ago
Sorry but why exactly should NIST be trusted? https://projectbullrun.org/dual-ec/vulnerability.html https://projectbullrun.org/dual-ec/vulnerability.html It seems from many sources that NIST were pushing a backdoored RNG source for a while. The main source for the ssh-keys arch wiki even says not to trust NIST. https://wiki.archlinux.org/index.php/SSH_keys https://wiki.archlinux.org/index.php/SSH_keys https://stribika.github.io/2015/01/04/secure-secure-shell.html https://stribika.github.io/2015/01/04/secure-secure-shell.ht...

usr1106 6y ago

Good that arstechnica clearly explains that SHA-1 is the problem here. The protocol in question is called ssh-rsa, which easily leads to the misunderstanding that RSA keys would be deprecated. If I as a non-cryptographer understood it correctly the keys can remain, but different fingerprints are needed. Is it so that you have fingerprints in known_hosts, but not in authorized_keys?

mkj 6y ago
The authorized_keys file will not change. ssh-rsa as a key format will stay (it isn't specific to sha1 or sha2), just the client and server need to upgrade to sign/verify session-specific signatures using sha256 instead of sha1. rsasign(sha1(sessiondata)) becomes rsasign(sha256(sessiondata)). OpenSSH CA certificates are more urgent to upgrade since those are/were long lived sha1 signatures - sha1 there got disabled a couple of releases ago I think. The article seems bit sensational and lacking understanding.
usr1106 6y ago
There are no fingerprints in authorized_keys. I should have looked into the file before speculating. So no updates to the file needed.

grizzles 6y ago

We need a new default hash algorithm for general purpose stuff, because sha512 is a bit too long for copy/paste imho. I propose shac = sha1sum(sha512sum(data)) - for sha concatenated. Thoughts?

tpetry 6y ago
Sha2 is designed to be truncated to the length you want to have
woodruffw 6y ago
It's probably better to just truncate your SHA-2/512 (or any other SHA-2 variant) output to 160 bits (and add a tag, to avoid confusing people). That being said, most people are probably willing to live with the 8 additional bytes required by SHA-2/224 (which, IIRC, is itself a truncated special case of SHA-2/256).
- grizzles 6y ago
  Good feedback. Thanks tpetry as well. I agree about the tag. It's a cultural oversight that all secure hashes aren't labelled as such. When one is used it ought to be identified by its respective hash algorithm, eg. sha1://7d157d7c000ae27db146575c08ce30df893d3a64
  - Dylan16807 6y ago
    It rarely matters, and that's not an insignificant amount of overhead, especially because you're putting those wasteful slashes in https://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address-mistake.html https://www.dailymail.co.uk/sciencetech/article-1220286/Sir-...
  - sneak 6y ago
    Are you familiar with multihash (which is used extensively in ipfs)? It’s an open standard and library and does exactly this (though the prefix tag itself is not human readable unless you are weird like us). I use it in my projects when I need to serialize hashes, as it has nice go and javascript libraries.

fortran77 6y ago

> Theoretically, the digests are supposed to be unique for every file, message, or other input fed into the function Given that the digests are shorter than the messages they are meant to identify, this is not at all a "theoretical" possibility (you can prove this with a "pigeonhole" proof).

dasnab 6y ago
I think they meant that the input should be unique for every two inputs actually fed into the function. That is, there are many, many collisions, but they won't ever be found in our lifetime.

rwmj 6y ago

One of the things we do at Red Hat is migrate virtual machines off RHEL 5-era Xen to modern KVM, and one of the problems we have is that you can no longer ssh into a RHEL 5 machine from a RHEL 8 machine because there's no common set of cyphers available. Currently you can work around this by relaxing the RHEL 8 machine's crypto policy to include "legacy"[1], although I wonder how long that option will be available. For reference RHEL 5 was released in 2007 and is supported to the end of this year for some customers. [1] http://libguestfs.org/virt-v2v-input-xen.1.html#ssh-authentication http://libguestfs.org/virt-v2v-input-xen.1.html#ssh-authenti...

wlll 6y ago
If I was running Redhat machines and had bought support to the end of the year I think I'd expect Redhat to release packages for RHEL 5 that let me SSH to them from RHEL 8 machines.
- quietbritishjim 6y ago
  Doesn't it defeat the object of using an old, stable edition of an operating system if you keep installing feature updates to it?
  - rwmj 6y ago
    Red Hat does update RHEL with new features, although not RHEL 5 which is now only getting security fixes. In this case there is a workaround (on the RHEL 8 / ssh client end) which is to enable legacy crypto policies. However you have to do this globally at least for all ssh connections (and our recommended command does it globally for the whole machine), and I guess there are reasons why the legacy policies are disabled by default, probably to do with possible MITM attacks against weak cyphers. So the situation isn't exactly ideal. Having said all that it would be up to me to actually fix this and I haven't looked into it in great detail since I don't believe any customers have asked about it. We only found out about it in our internal product QA.
    - 6y ago

knorker 6y ago

So if ssh-rsa is going away, does that mean millions of smart card second factors will be bricked? Or since it's not RSA being taken out, is this just a matter of updating .authorized_keys with new SHA256 hashes for the same keys?

tialaramex 6y ago
Neither. The smart card just makes RSA signatures over input data, and an updated SSH client will use SHA256 rather than SHA-1, as input data so nothing changes for the smart card. The Authorized Keys list is of actual public keys, not hashes, so that doesn't change. That's why the line length is much longer for a larger key (e.g. 4096-bit RSA) and shorter for small key like ECDSA.
- knorker 6y ago
  Doh, of course. Think-o on my part. Thanks. So in what sense is "ssh-rsa" going to be removed? Just as a protocol enum, with no user-visible impact for these purposes?
  - tialaramex 6y ago
    Both future clients and servers will refuse to do this algorithm, so it becomes user visible if your clients are not new enough to know anything acceptable to your servers or vice versa. The ssh-rsa algorithm is one of two authentication algorithms described in the first SecSH (IETF standardised SSH version 2) documents in 2006. The other (ssh-dsa) was never very popular and has been untrustworthy for a long time. So up until this point even a very old client or server could expect to interoperate with the latest software using ssh-rsa. Of course an individual setup might forbid this, but in general it could work. The announced change in OpenSSH means it will be necessary to give up on very old systems because they're incompatible, or else use a shim to restore compatibility if that's essential for you. This previously happened with SSH version 1 - once upon a time OpenSSH could interoperate with SSHv1, then it required a config override to allow that, and then they removed the compatibility from their source code entirely, but SSHv1 pre-dates the widespread modern popularity of SSH, so it probably had less impact than this will.