Open Bug 1968647 Opened 6 months ago Updated 2 months ago

SHA1 removal due to new NIST requirements

Categories

(NSS :: Libraries, enhancement)

Product:
NSS
Component:
Libraries
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: msirringhaus, Unassigned)

References

Details

NIST declared that the SHA1 algorithm shall not be used starting in January 2031. This means you can't use SHA1 in either of the following scenarios anymore:

  • Your system is configured to run in FIPS mode
  • Your system is configured to be in a Common Criteria compliant state
  • You run the software in a government institution (which is affected by the CNSA 2.0 whitepaper)

2031 sounds like still a long way out. However, as certification processes and implementation times can be quite long, we would like to start with this sooner, rather than later. Especially given that we have to deal with persisted data which uses SHA1 for verification of credentials (i.e. SHA1 hashes of passwords in databases). This means, we cannot simply deactivate the algorithm, as we also need a migration path for old databases in case these cannot be (re-)setup.

We know Mozilla does not really care about FIPS, and we would be willing to provide patches or carry them outside the tree.

However, we want to avoid implementing solutions on our own, when Mozilla or RedHat may have already plans for dealing with this, where we could join forces, instead.

The (somewhat) newly released CNSA 2.0 standard now requests the hash output length to be at least 384 or 512 bits longs, regarding SHA ([1]).
Therefore, when migrating away from SHA1, SHA(2|3)-(384|512) should be considered.

[1] https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF

We're most moved away in NSS. There is an issue that Mozilla was still signing browser extensions with SHA1, so the browser would explicitly turn just raw signing on for SHA1. SHA1 is already turned off for certificate signatures. Once those are handled, we can remove the explicit policy override in Firefox. That will allow you to turn off SHA-1 by policy everywhere. (I think we already turn it off in our RHEL releases for everything but extension signing... and then only because our pref has been overridded). There's a bug somewhere about the Extension signing, but I couldn't find it in a quick search.

The most pressing issue we're seeing is this:

  1. SHA1 must be removed from code.
  2. The browser's password database hashes the master password with the SHA1 hash.

This means users' password database must be migrated, and it must be done using an external tool that can use SHA1 to decrypt before applying a stronger hash and re-encrypting with the resulting key.

Please correct me if I'm wrong on any of the details.

Hmmm I would argue that the sha1 use there is a mixing function that doesn't depend on the security properties of SHA1. That value is used in a PBE with SHA-256. Still, It probably makes sense to migrate that. (I looks like we can use the salt length to figure out how the DB is encoded, so we can use SHA-256 and create a salt with a SHA-256 hash length. The code will be fine as long as the hash length < 256 bytes (2048bits). Old versions of NSS wouldn't be able to read the encrypted portions of the database (keys, signatures, etc.), so can't log in, but new versions of NSS can easily read old version. You wouldn't need a special tool, just changing the password on the database will upgrade it. You would probably need to drop dbm support, but that's already the default in NSS.

I also see that we are using SHA1 to sign attributes. That is a simple fix because the hash algorithm is included in the signature, so changing it won't affect the ability of older versions of NSS to read the entry.

You probably should use this as a meta bug and list the individual issues as separate bugs.

Hmm looks like some of the self tests would need to be updated that use sha1... Not something that's going to cause issues, but should also be noted.

Are you most worried about used in the validated portion of the code (softoken/freebl?) or the wider NSS in general. In the wider case we are using policy to control things. Even after 2031 we'll have sha1 code in softoken, just like we have MD-5 code in softoken, their use won't get a FIPS indicator, however, and the NSS protocol use will be gated by policy.

Are people using webcrypto to sign with SHA-1? (and you pass a SHA-1 hash to an RSA sign operation).
Webcrypto already has FIPS issues, though. Passing key blobs through the web unencrypted isn't exactly FIPS friendly :)

Depends on: 1990242
You need to log in before you can comment on or make changes to this bug.