Closed
Bug 650296
Opened 14 years ago
Closed 10 years ago
PSM may report a different certificate error than what was originally encountered
Categories
(Core :: Security: PSM, defect)
Core
Security: PSM
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: briansmith, Unassigned)
References
Details
When certificate chain verification fails, PSM does another verification in order to learn the details of the failure through the error log. But, the errors encountered by the second verification may not be the same as the errors encountered in the first verification. For example, AFAICT, an OCSP request could fail in the first verification but then succeed in the second verification (or vice versa). One solution would be to have the initial certificate chain verification generate the log.
Reporter | ||
Updated•14 years ago
|
Blocks: pkix-default
Reporter | ||
Updated•14 years ago
|
No longer blocks: pkix-default
Comment 1•14 years ago
|
||
(In reply to comment #0) > One solution would be to have the initial certificate chain verification > generate the log. The only other approach would be to commit to making the entire cert verification process reproducible. I think the above is much more reasonable. Currently: - PSM's AuthCertificateCallback wraps the standard SSL_AuthCertificate (which does no logging) with additional status reporting but does not change the result. - PSM's nsNSSBadCertHandler (a) does a second verification with logging (the logic parallels SSL_AuthCertificate), (b) maps the log to override bits, and (c) makes a decision based on the override bits, STS, and existing cert overrides. Obviously, the single verification with logging needs to occur during AuthCertificateCallback. So we have a few options: 1. In AuthCertificateCallback, replace the call to SSL_AuthCertificate with (a-b), save the override bits somewhere, and leave (c) in nsNSSBadCertHandler. 2. In AuthCertificateCallback, replace the call to SSL_AuthCertificate with (a), save the log somewhere, and leave (b-c) in nsNSSBadCertHandler. 3. Add logging support based on (a) to SSL_AuthCertificate, have PSM enable it, and leave (b-c) in nsNSSBadCertHandler. Of these options, #1 and #2 do not touch NSS, while #3 requires adding an appropriate API for the logging to NSS. In return, #3 eliminates the code duplication between SSL_AuthCertificate and nsNSSBadCertHandler, which makes it easier to add new server authentication schemes to NSS and PSM. E.g., my DANE prototype (https://mattmccutchen.net/cryptid/#nss-dane) currently patches only SSL_AuthCertificate, so nsNSSBadCertHandler ignores DANE errors or hits the NS_NOTREACHED("why did NSS call our bad cert handler if all looks good? Let's cancel the connection") if the only error was a DANE error. With #3, I would get proper PSM reporting of DANE errors for free, though for full integration I would still have to modify nsNSSBadCertHandler to add a new override bit. So I have a personal interest in #3 being chosen. However, it sounds like the single verification is going to be used for EV as well (bug 650307), so #3 would mean passing whatever parameters are required for that in and out of NSS as well. This may tilt the judgment in favor of #1 or #2.
Reporter | ||
Updated•13 years ago
|
Assignee: bsmith → nobody
Reporter | ||
Comment 2•10 years ago
|
||
As part of the migration to mozilla::pkix and the subsquent work on it, this bug was fixed. I'm not sure which bug fixed it. This can be verified by noticing that there's no certificate verification in SSLServerCertVerification.cpp except the one in AuthCertificate.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Updated•10 years ago
|
Depends on: mozilla::pkix
You need to log in
before you can comment on or make changes to this bug.
Description
•