Bug 1508595

Summary:	Regression in handling unknown signature algorithms extensions
Product:	Red Hat Enterprise Linux 7	Reporter:	Alicja Kario <hkario>
Component:	nss	Assignee:	Daiki Ueno <dueno>
Status:	CLOSED ERRATA	QA Contact:	Stanislav Zidek <szidek>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	7.3	CC:	dueno, hkario, mthacker, nmavrogi, szidek
Target Milestone:	rc	Keywords:	Triaged, ZStream
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	nss-3.43.0-2.el7	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1410573
Clones:	1566466 1568899 1644878 (view as bug list)		Environment:
Last Closed:	2019-08-06 13:08:26 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:	1410573, 1645231
Bug Blocks:	1566466, 1568899, 1644878

Description Alicja Kario 2017-11-01 18:22:46 UTC

When server receives a list of signature algorithms that are unrecognised to it, it replies with a decode_error alert instead of handshake_failure alert.

This is a regression compared to Bug #1410573 and RFC 5246 violation.

+++ This bug was initially created as a clone of Bug #1410573 +++

Description of problem:
When Client Hello received by server does not include algorithms known to server, the server signs Server Key Exchange with a sha1+rsa signature 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 with invalid values in signature_algorithms extension

Actual results:
Server replies with a SKE message signed with SHA-1

Expected results:
handshake_failure alert message

Additional info:
This is RFC 5246 violation:

   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 21 errata-xmlrpc 2019-08-06 13:08:26 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/RHSA-2019:2237