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):
Steps to Reproduce:
1. Send Client Hello with invalid values in signature_algorithms extension
Server replies with a SKE message signed with SHA-1
handshake_failure alert message
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
("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.
Hubert, can this bug be fixed by upgrading to NSS 3.28 ?
Yes, I've verified that 3.28.0 does fix this issue.
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.
Hubert, can you help with qa-ack, if you want to track this for 7.4.0 ?
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.