4

I got an automated PCI security test result that checked various server configurations. The automated test determined the server to be unsafe due to the use of sha1 algorithm in some elements of the ssh configuration.

The configuration can be seen when running ssh -vvv, so here's the relevant part of that output. I snipped out the other algorithms that are available on this particular server, but several are available.

debug2: KEX algorithms: ...snip...diffie-hellman-group14-sha1
debug2: MACs ctos: hmac-sha1...snip...

It's the use of:

  • diffie-hellman-group14-sha1 in the key exchange algorithms
  • hmac-sha1 in the MACs from client to server

I've searched this site a bit and I don't see much data about whether these algorithms are 1) in use 2) considered insecure for a PCI compliant site in 2019.

Improve this question
4
  • 3
    The relevant attack for SHA1 collisions to create a fake certificate that matches a real one, which is why it shouldn't be used. An applicant could create two different certificate requests, one for their legit site and one for the target, and get the legit one signed by a CA - and then reuse the signature for the malicious certificate. It isn't the individual website that's vulnerable for using SHA1 - it's the CA that needs to ban SHA1. shattered.io - HMAC is however NOT affected by that kind of collision attacks, and HMAC-SHA1 is still safe although NOT recommended
    – Natanael
    Commented Feb 21, 2019 at 21:05
  • 6
    @Natanael This is a key exchange algorithm and MAC for ssh, CAs are not relevant. HMAC-SHA1 is perfectly fine, and while I don't know if collisions would matter for that key exchange algorithm, my intuition is that they would not (ie it's likely still safe). Should probably investigate further though.
    – AndrolGenhald
    Commented Feb 21, 2019 at 21:17
  • 2
    I second that it is most likely not an issue. The attack is forging a identical hash whike knowing the original payload. For this attack to work, one would probably have to know a valid key. But I don't know the internals of the attack, it might have mechanisms/implications that make SSH easier-than-buteforce to crack.
    – J.A.K.
    Commented Feb 21, 2019 at 22:33
  • 1
    @AndrolGenhald in the key exchange I believe SHA1 is essentially used as either a KDF (hash the key exchange output to produce session keys) or for authentication (hash and sign session values), or perhaps both. Can somebody check the spec? I do not believe it's immediately vulnerable for these uses, but it's still not recommended.
    – Natanael
    Commented Feb 21, 2019 at 23:23

2 Answers 2

Reset to default
5
+50

Rule of thumb: SHA1 is potentially insecure when used on relatively static data, e.g. code signing, digital signatures, file hashes.

This is reflected by the PCI FAQ:

When a hash function is applied iteratively (e.g. HMAC, PBKDF2) it is substantially less affected by collisions than their underlying hash functions per se. Ref. HMAC (Wikipedia). HMAC-SHA1 (and HMAC-MD5) are still safe from a security perspective (in 2019).

Similarly, the dynamic nature of Diffie-Hellman means its weaknesses resides on the number of bits governing its primes rather than the hash function it employs. Elaborating on what ConsideredHarmful noted: diffie-hellman-group14-sha1 is safe because it utilizes a 2048-bit prime whereas diffie-hellman-group1-sha1 is not because it only uses 1024-bits.

Improve this answer
3
  • Very interesting, thanks for the info! I noticed from the PCI FAQ that "The PCI Council defers to ... NIST and ANSI" - I wonder if either of those organizations have standards that specifically say whether this SSH configuration is insecure or not.
    – greggles
    Commented Apr 22, 2019 at 18:15
  • The de facto document to check would be: csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final (as of 4/2019 but always look for latest revision)... SHA1 for digest not allowed (as expected); allowed for HMAC; allowed for Diffie-Hellman - latter two criteria are centered around key length rather than hash function.
    – HTKLee
    Commented Apr 22, 2019 at 18:27
  • I wonder if this answer is worth updating after sha-mbles.github.io ? Thanks!
    – greggles
    Commented Jan 7, 2020 at 19:12
3

None of these findings are critical, they are simply best-practice. There is no practical general attack on SHA1 better than brute force (as of this writing). Natanael correctly pointed out in the thread above that SHA1 collisions do not break hmac-sha1.

diffie-hellman-group14-sha1 is still acceptable for PCI as it is a 2048-bit group: https://weakdh.org/sysadmin.html.

This is equivalent to a ~112 bit symmetric key (the effective security of 3DES) which is considered acceptable by NIST until 2023 (see Table 1, page 128 of NIST SP800-131A rev 2).

For AES key exchange, if you wish to maintain >= 128 bits of security, you should probably be using a DH group >= 3200 bits (see RFC-3526). The smallest group that meets this requirement is diffie-hellman-group16-sha512 (See RFC-5656).

If you can safely drop support immmediately for non-elliptic curve key exchange and SHA1-based HMACs then do so. Otherwise, start planning now as cryptographic migration projects are a huge pain and you will probably need to do so eventually.

Note that some FIPS requirements mandate the use of hmac-sha1.

Improve this answer
1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .