Closed Bug 982340 Opened 6 years ago Closed 4 years ago

CertVerifier/NSSCertDBTrustDomain incorrectly uses the NSS trustbit in the case of SSLClient

Categories

(Core :: Security: PSM, defect)

x86_64
Linux
defect
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: cviecco, Assigned: cviecco)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

No description provided.
Please include some context so that people following the tracking bug know what's going on.

Thanks,
Monica
Summary: Insanity::pkix incorrectly uses the NSS trustbit in the case of SSLClient → mozilla::pkix incorrectly uses the NSS trustbit in the case of SSLClient
Assignee: nobody → cviecco
So this solves MOST of the issues, I still got to figure out why and explicit distrust over an intermediate does not work. Potentially problematic issues:

1/ what do you think of having the two constructors 
2. the new input paramter is not an enum but an unsigned int.
Attachment #8409061 - Flags: feedback?(dkeeler)
Attachment #8409061 - Flags: feedback?(brian)
Comment on attachment 8409061 [details] [diff] [review]
fix-ssl-client-trust-mozpkix

Review of attachment 8409061 [details] [diff] [review]:
-----------------------------------------------------------------

I'm not sure we should spend a lot of effort supporting certificateUsageSSLClient, particularly when it requires a different trust bit on the root. I think we should just document that the way NSSCertDBTrustDomain interprets NSS's certdb trust bits is that if a cert has the CERTDB_TRUSTED_CA, it can be a trust anchor for any usage. If not, then it isn't a trust anchor for anything.

::: security/manager/ssl/tests/unit/test_cert_trust.js
@@ -128,5 @@
>    // Now tests on the SSL trust bit
>    setCertTrust(cert_to_modify_trust, 'p,C,C');
>    check_cert_err_generic(ee_cert, SEC_ERROR_UNTRUSTED_ISSUER,
>                           certificateUsageSSLServer);
> -  check_cert_err_generic(ee_cert, useMozillaPKIX ? 0  //XXX Bug 982340

I'm not actually sure this is a bug - when we verify for certificateUsageSSLClient, CertVerifier uses the trustEmail bit, which is set in this case.

@@ -157,5 @@
>    check_cert_err_generic(ee_cert, isRootCA ? useMozillaPKIX ? SEC_ERROR_UNKNOWN_ISSUER
>                                                              : SEC_ERROR_UNTRUSTED_ISSUER
>                                             : 0,
>                           certificateUsageSSLServer);
> -  check_cert_err_generic(ee_cert, isRootCA ? useMozillaPKIX ? 0  // XXX Bug 982340

Same here.
Attachment #8409061 - Flags: feedback?(dkeeler) → feedback-
No longer blocks: mozilla::pkix
Comment on attachment 8409061 [details] [diff] [review]
fix-ssl-client-trust-mozpkix

I think one reviewer is good enough, and I'm happy for that to be David.

Please document (whereever the trust flags are defined in NSS) which flags correspond to which things. For example, is CERTDB_TRUSTED_CLIENT_CA supposed to be used for id-kp-emailProtection too?

Note that any place Firefox is verifying a certificate for id-kp-clientAuth is almost definitely a bug. The server (hopefully) has a totally different set of trust anchors and usually there's no reason for Firefox to trust any of those trust nachors. Thus, it doesn't make sense for Firefox to try to verify an SSL client cert chain.
Attachment #8409061 - Flags: feedback?(brian)
Summary: mozilla::pkix incorrectly uses the NSS trustbit in the case of SSLClient → CertVerifier/NSSCertDBTrustDomain incorrectly uses the NSS trustbit in the case of SSLClient
This doesn't seem to be a problem in practice.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.