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 1399774 - NSS signs Server Key Exchange message with rsa+sha1 if it doesn't recognize algorithms in Client Hello
Summary: NSS signs Server Key Exchange message with rsa+sha1 if it doesn't recognize a...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nss
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Daiki Ueno
QA Contact: Hubert Kario
URL:
Whiteboard:
Depends On:
Blocks: 1509401
TreeView+ depends on / blocked
 
Reported: 2016-11-29 17:28 UTC by Hubert Kario
Modified: 2018-04-10 09:25 UTC (History)
3 users (show)

Fixed In Version: nss-3.34.0-0.1.beta1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1509401 (view as bug list)
Environment:
Last Closed: 2018-04-10 09:23:57 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:0679 0 None None None 2018-04-10 09:25:17 UTC

Description Hubert Kario 2016-11-29 17:28:27 UTC 
Description of problem:
When NSS server receives Client Hello with signature_algorithms extension that doesn't list any algorithms that it understands, it doesn't abort the connection but continues and signs the Server Key Exchange message with sha1+rsa algorithm.

Version-Release number of selected component (if applicable):
nss-3.21.0-17.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1. Send client hello that lists only RSA-PSS signature algorithms and PFS ciphersuites

Actual results:
Server responds with Server Hello, Certificate and so on

Expected results:
handshake_failure alert

Additional info:
This is in direct violation of RFC 5246 MUST clause:

   If the client does not support the default algorithms (...),
   it MUST send the
   signature_algorithms extension, listing the algorithms it is willing
   to accept.

("default algorithms" refers to sha1+rsa, sha1+dsa and sha1+ecdsa pairs)

   If the client has offered the "signature_algorithms" extension, the
   signature algorithm and hash algorithm MUST be a pair listed in that
   extension.  Note that there is a possibility for inconsistencies
   here.  For instance, the client might offer DHE_DSS key exchange but
   omit any DSA pairs from its "signature_algorithms" extension.  In
   order to negotiate correctly, the server MUST check any candidate
   cipher suites against the "signature_algorithms" extension before
   selecting them.  This is somewhat inelegant but is a compromise
   designed to minimize changes to the original cipher suite design.
Comment 1 Kai Engert (:kaie) (inactive account) 2016-12-07 15:02:29 UTC 
Hubert,

- is this a regression?

- can the same bug be seen with upstream in Fedora?
Comment 2 Hubert Kario 2016-12-13 12:02:54 UTC 
(In reply to Kai Engert (:kaie) from comment #1)
> Hubert,
> 
> - is this a regression?

I don't think so (I'm testing now), but with RSA-PSS being added to TLS, it now becomes important to fix - incorrect behaviour on server part makes it more likely that clients will misbehave

> - can the same bug be seen with upstream in Fedora?

yes, I can reproduce it with nss-3.27.0-1.2.fc24
Comment 3 Hubert Kario 2016-12-13 15:58:25 UTC 
(In reply to Kai Engert (:kaie) from comment #1)
> Hubert,
> 
> - is this a regression?

sort of, nss-3.19.1-8.el6_7.x86_64 does close connection in some cases when it receives unrecognised sigalgs
Comment 4 Kai Engert (:kaie) (inactive account) 2017-02-24 13:59:46 UTC 
Hubert, is there an upstream bug?
Comment 5 Hubert Kario 2017-02-24 17:42:13 UTC 
no, but I see it is fixed in 3.29
Comment 6 Kai Engert (:kaie) (inactive account) 2017-02-24 21:00:09 UTC 
if it's fixed in 3.29, but you don't know which bug fixed it, it's unknown which patch would have to be backported.

so 7.5.0
Comment 7 Hubert Kario 2017-02-27 12:23:14 UTC 
I meant it as "I have tested 3.29 and it is fixed in there", not "I verified the fix to be in 3.29".

I'm quite sure the bug was fixed because of the work on rsa-pss, and since we plan to pick up it, we will need to pick up this fix too.
Comment 8 Kai Engert (:kaie) (inactive account) 2017-02-27 16:16:38 UTC 
Hubert, it's fixed in 3.29, but not fixed in 3.28 ?

We need to know which patch(s) fixes it, before we can agree to fix it (and set devel-ack).

Daiki, Hubert, do you have ideas how to identify and test which patch is required?
Comment 10 Hubert Kario 2017-03-01 13:25:28 UTC 
I've verified that it is fixed in nss-3.28.1-1.3.fc24.x86_64
Comment 12 Hubert Kario 2017-03-01 13:37:06 UTC 
> I meant it as "I have tested 3.29 and it is fixed in there", not "I verified the fix to be in 3.29".

sigh, still not clear

> I meant it as "I have tested 3.29 and it is fixed in there", not "I verified the fix to be introduced in 3.29".
Comment 22 errata-xmlrpc 2018-04-10 09:23:57 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-2018:0679
Note You need to log in before you can comment on or make changes to this bug.