Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1410573 - RFC violation in handling signature algorithms extensions (fix by rebase to 3.28.x)
RFC violation in handling signature algorithms extensions (fix by rebase to 3...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nss (Show other bugs)
7.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Daiki Ueno
Hubert Kario
: Rebase
Depends On:
Blocks: 1508595 1566466 1644878
  Show dependency treegraph
 
Reported: 2017-01-05 13:53 EST by Hubert Kario
Modified: 2018-10-31 15:20 EDT (History)
2 users (show)

See Also:
Fixed In Version: nss-3.28.3-4.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1508595 (view as bug list)
Environment:
Last Closed: 2017-08-01 12:50:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:1977 normal SHIPPED_LIVE nss bug fix and enhancement update 2017-08-01 13:57:47 EDT

  None (edit)
Description Hubert Kario 2017-01-05 13:53:05 EST
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 2 Kai Engert (:kaie) (inactive account) 2017-01-11 09:19:31 EST
Hubert, can this bug be fixed by upgrading to NSS 3.28 ?
Comment 3 Hubert Kario 2017-01-12 06:48:40 EST
Yes, I've verified that 3.28.0 does fix this issue.
Comment 4 Kai Engert (:kaie) (inactive account) 2017-01-12 07:54:27 EST
We plan to upgrade both 7.4.0 and 7.3.z to NSS 3.28.x by March, so this will be done by our rebase.
Comment 5 Kai Engert (:kaie) (inactive account) 2017-02-24 09:13:02 EST
Hubert, can you help with qa-ack, if you want to track this for 7.4.0 ?
Comment 8 errata-xmlrpc 2017-08-01 12:50:07 EDT
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.