Bug 1399774
| Summary: | NSS signs Server Key Exchange message with rsa+sha1 if it doesn't recognize algorithms in Client Hello | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Alicja Kario <hkario> | |
| Component: | nss | Assignee: | Daiki Ueno <dueno> | |
| Status: | CLOSED ERRATA | QA Contact: | Alicja Kario <hkario> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 7.3 | CC: | hkario, kengert, szidek | |
| Target Milestone: | rc | |||
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | nss-3.34.0-0.1.beta1.el7 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1509401 (view as bug list) | Environment: | ||
| Last Closed: | 2018-04-10 09:23:57 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: | ||||
| Bug Blocks: | 1509401 | |||
Hubert, - is this a regression? - can the same bug be seen with upstream in Fedora? (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 (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 Hubert, is there an upstream bug? no, but I see it is fixed in 3.29 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 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. 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? I've verified that it is fixed in nss-3.28.1-1.3.fc24.x86_64 > 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". 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 |
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.