RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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...
Keywords:
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:
Depends On:
Blocks: 1309777 1444136
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)

Fixed In Version: nss-3.28.3-5.el7
Doc Type: Enhancement
Doc Text:
_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)
Environment:
Last Closed: 2017-08-01 16:47:42 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Mozilla Foundation 1345106 0 -- RESOLVED Don't use SHA1 by default for signatures in the NSS library and in certutil, crlutil and cmsutil 2020-09-04 12:38:41 UTC
Red Hat Product Errata RHEA-2017:1977 0 normal SHIPPED_LIVE nss bug fix and enhancement update 2017-08-01 17:57:47 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 18 Daiki Ueno 2017-03-16 09:45:33 UTC 
Backported as:
http://pkgs.devel.redhat.com/cgit/rpms/nss/commit/?h=rhel-7.4&id=893dbb4c884ec9a774f97e6c66aceb12752c806d
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.