Bug 1509401

Summary: NSS signs Server Key Exchange message with rsa+sha1 if it doesn't recognize algorithms in Client Hello
Product: Red Hat Enterprise Linux 6 Reporter: Alicja Kario <hkario>
Component: nssAssignee: Daiki Ueno <dueno>
Status: CLOSED ERRATA QA Contact: Stefan Dordevic <sdordevi>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.9CC: dueno, hkario, kengert, mkolaja, mthacker, qe-baseos-security, sdordevi, szidek
Target Milestone: pre-dev-freeze   
Target Release: 6.10   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: nss-3.36.0-4.el6 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1399774 Environment:
Last Closed: 2018-06-19 05:10:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1399774, 1485481    
Bug Blocks:    

Description Alicja Kario 2017-11-03 17:11:14 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.27.1-13.el6.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 12 errata-xmlrpc 2018-06-19 05:10:10 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:1865