Bug 1309781 - NSS tools should not use SHA1 by default when generating digital signatures/certificates
Summary: NSS tools should not use SHA1 by default when generating digital signatures/c...
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nss
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Daiki Ueno
QA Contact: Hubert Kario
Mirek Jahoda
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks: 1444136 1309777
TreeView+ depends on / blocked
 
Reported: 2016-02-18 16:43 UTC by Nikos Mavrogiannopoulos
Modified: 2019-01-04 09:57 UTC (History)
8 users (show)

(edit)
_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.
Clone Of: 1309779
: 1444136 (view as bug list)
(edit)
Last Closed: 2017-08-01 16:47:42 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:1977 normal SHIPPED_LIVE nss bug fix and enhancement update 2017-08-01 17:57:47 UTC
Mozilla Foundation 1345106 None None None 2019-01-04 09:57 UTC

Description Nikos Mavrogiannopoulos 2016-02-18 16:43:40 UTC
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.

Comment 2 Kai Engert (:kaie) (inactive account) 2016-02-24 13:43:28 UTC
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

Comment 3 Kai Engert (:kaie) (inactive account) 2016-02-24 13:44:30 UTC
I believe certutil is the only NSS command line tool used to create certificates.

Comment 4 Kai Engert (:kaie) (inactive account) 2016-02-24 13:47:10 UTC
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.

Comment 7 Hubert Kario 2016-06-24 13:28:20 UTC
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)

Comment 8 Kai Engert (:kaie) (inactive account) 2016-06-28 15:51:49 UTC
This will likely get postponed to RHEL 7.4.0, there was agreement that's acceptable.

Comment 9 Kai Engert (:kaie) (inactive account) 2016-06-29 12:18:46 UTC
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.

Comment 11 Kai Engert (:kaie) (inactive account) 2017-03-07 14:30:43 UTC
I've filed upstream bug https://bugzilla.mozilla.org/show_bug.cgi?id=1345106

We should prepare the changes upstream.

Comment 12 Kai Engert (:kaie) (inactive account) 2017-03-08 20:06:29 UTC
Handling signtool might be more complicated, I've filed a separate bug for it:
  https://bugzilla.mozilla.org/show_bug.cgi?id=1345528

Comment 13 Kai Engert (:kaie) (inactive account) 2017-03-09 15:39:18 UTC
(In reply to Kai Engert (:kaie) from comment #12)
> Handling signtool might be more complicated, I've filed a separate bug for
> it:
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1345528

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.

Upstream bug
  https://bugzilla.mozilla.org/show_bug.cgi?id=1345106

has a patch, which we should be able to backport for RHEL 7.4.0

Comment 14 Kai Engert (:kaie) (inactive account) 2017-03-09 15:40:24 UTC
(In reply to Kai Engert (:kaie) from comment #13)
> Upstream bug
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1345106
> 
> 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.

Comment 15 Kai Engert (:kaie) (inactive account) 2017-03-09 15:41:15 UTC
I just noticed that we haven't yet all approval flags.

Hubert/Standa, could you please grant qa-ack?

Comment 17 Kai Engert (:kaie) (inactive account) 2017-03-15 16:40:06 UTC
removing signtool tracker, postponed to later.

The other upstream patch is ready to be picked up.

Comment 21 Hubert Kario 2017-04-20 16:13:08 UTC
I've moved the signtool part of the bug to bug 1444136.

Comment 26 errata-xmlrpc 2017-08-01 16:47:42 UTC
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.

https://access.redhat.com/errata/RHEA-2017:1977


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