Closed
Bug 1294975
Opened 8 years ago
Closed 8 years ago
NSS should respond with decode_error rather than illegal_parameter when CertificateRequest.signature_algorithms is empty
Categories
(NSS :: Libraries, defect)
NSS
Libraries
Tracking
(Not tracked)
RESOLVED
FIXED
3.28
People
(Reporter: ekr, Unassigned)
References
Details
http://searchfox.org/mozilla-central/source/security/nss/lib/ssl/tls13con.c#1330 The spec is ambiguous but decode_error seems like the best interpretation and BoGo checks.
Comment 1•8 years ago
|
||
This isn't that easy to fix. The SHA-1 test passes when I make the change, but the other test fails. It's clear that I don't know how to interpret the output from bogo: FAILED (ClientAuth-NoFallback-TLS13) bad error (wanted '' / 'remote error: error decoding message'): local error 'local error: bad record MAC', child error 'exit status 1', stdout: stderr: Handshake failed with error=-12256:SSL_ERROR_RX_MALFORMED_CERT_REQUEST::SSL received a malformed Certificate Request handshake message. Clearly the stderr is what NSS produces. The first line implies that it's looking for something specific out of NSS (which I presume is the "remote"). The test lists ":DECODE_ERROR:", so why doesn't it actually print that? (I tried updating the erro mappings and that was a catastrophic failure.) I think that the real problem here is that NSS generates and sends an unencrypted alert. Bogo expects to see an encrypted flight (handshake traffic keys) and therefore is unable to parse the alert. I guess we should fix that.
Comment 2•8 years ago
|
||
https://hg.mozilla.org/projects/nss/rev/2bfa7b5125965d22260153686bacbf6055cdafaa
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.28
You need to log in
before you can comment on or make changes to this bug.
Description
•