_nss_ and _nss-util_ now use SHA-256 by default
With this update, the default configuration of the NSS library has been changed to use a stronger hash algorithm when creating digital signatures. With RSA, EC, and 2048-bit (or longer) DSA keys, the SHA-256 algorithm is now used.
Note that also the NSS utilities, such as *certutil*, *crlutil*, and *cmsutil*, now use SHA-256 in their default configurations.
Description of problem:
SHA1 was published in 1993 and is still in wide use today. However there are several weaknesses and the algorithms is considered today cryptographically broken (less effort than brute force is required). It is highly likely we will have collision attacks in the near future; i.e., forged certificates. For that it is recommended for our tools which deal with digital signatures to no longer use the SHA1 as a hash function by default.
For maximum compatibility with old software we recommend the SHA2-256 algorithm to be used as the default replacement.
As such, it is recommended for all of the included in NSS tools and shipped configuration files, to switch from SHA1 to SHA2-256 when generating certificates or digital signatures.
Using a RHEL 7.2.z system, with certutil default parameters, certutil is already using SHA256 signatures.
certutil -d . -S -n "test" -t ,, -s "CN=test" -x -z /proc/uptime
certutil -d . -L -n test |grep SHA
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
I believe certutil is the only NSS command line tool used to create certificates.
Actually, we should do more careful inspection.
We have signtool, which is used to sign jar/xpi files.
We also have cmsutil. That leads to the general question about the status of SHA1 in S/MIME.
So the full list of tools in nss-tools that can do signatures are: certutil, cmsutil, crlutil and signtool
Do we consider Password-Based Encryption? Then the Key Derivation Functions in pk12util would qualify too.
Using nss-3.21.0-13.el7.x86_64 I see the tools not using SHA256 in default configuration in following scenarios:
cmsutil when creating a signed enveloping document
signtool when creating and signing a jar file (both the mainfest hashes and the signature in the .rsa file)
This will likely get postponed to RHEL 7.4.0, there was agreement that's acceptable.
Postponing. I won't be able to quickly change the behaviour of the tools that Hubert mentioned in comment 7. It might require investigation, if the applications (S/MIME, JAR signatures) actually support signatures with SHA256.
I've filed upstream bug https://bugzilla.mozilla.org/show_bug.cgi?id=1345106
We should prepare the changes upstream.
Handling signtool might be more complicated, I've filed a separate bug for it:
(In reply to Kai Engert (:kaie) from comment #12)
> Handling signtool might be more complicated, I've filed a separate bug for
I suggest we include signtool, see my comments upstream.
Our change would likely break compatibility with other verification tools.
Hubert, thanks for your research which NSS tools create signatures.
I suggest to restrict this bug to crlutil, certutil, cmsutil.
has a patch, which we should be able to backport for RHEL 7.4.0
(In reply to Kai Engert (:kaie) from comment #13)
> Upstream bug
> has a patch, which we should be able to backport for RHEL 7.4.0
Daiki, could you please pick up the upstream patch for the next 7.4.0 nss package respin, after it's checked in upstream? (Might need another day, just waiting for a final comment from Bob.) Thank you.
I just noticed that we haven't yet all approval flags.
Hubert/Standa, could you please grant qa-ack?
removing signtool tracker, postponed to later.
The other upstream patch is ready to be picked up.
I've moved the signtool part of the bug to bug 1444136.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.