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


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:0679 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.