991209 - www.paket.de does not load with mozilla::pkix enabled

Status: RESOLVED FIXED

(Core :: Security: PSM, defect)

Description

[Sören Hentzschel]

STR:

1. Make sure that security.use_mozillapkix_verification is enabled
2. Go to https://www.paket.de

Expected:

The website loads as expected

Actual:

Error code: sec_error_inadequate_cert_type

(I know bug 982292, but since bug 982292 is marked as fixed I don't know if it's a dupe or another bug)

Comment 1

[Dana Keeler (she/her) (use needinfo) [:keeler]]

One of the intermediate certificates has an extended key usage extension with the 'OCSP Signing' usage. Currently we disallow that unless we're specifically verifying a certificate for an OCSP response (see pkixcheck.cpp: CheckExtendedKeyUsage). Looking at the BRs (appendix B, section 2G), intermediate certificates may have this usage included. I think we need to change the implementation to treat EEs differently from intermediates.

Comment 2

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Dana Keeler (:keeler) from comment #1)
> One of the intermediate certificates has an extended key usage extension
> with the 'OCSP Signing' usage.

Right. The "DPDHL TLS CA I3" intermediate has the id-kp-OCSPSigning EKU. That means that the "DPDHL TLS CA I3" certificate can sign its own OCSP responses by signing an OCSP response with its own certificate embeded as the delegated OCSP response signing certificate.

> Looking at the BRs (appendix B,
> section 2G), intermediate certificates may have this usage included.

Appendix B section 2G says other values are allowed. However, it doesn't explicitly say that *this* value is allowed. There is an important reason why we disallow CA certificates from having the id-EKU; see below.

> Currently we disallow that unless we're specifically verifying a
> certificate for an OCSP response (see
> pkixcheck.cpp: CheckExtendedKeyUsage).

> I think
> we need to change the implementation to treat EEs differently from
> intermediates.

I disagree. At least in the long term, we should keep this restriction, because this restriction helps prevent certificates from signing their own OCSP responses, which is a fundamentally important safety consideration.

I think we should work with GlobalSign to try to get that intermediate certificate replaced on its customer's systems.

There is another way that we could/should prevent a certificate from being able to forge OCSP responses for itself: When verifying an OCSP response's signature, we could verify that the public key of the OCSP response signer is not equal to the public key of the certificate for which the OCSP response applies.

Comment 3

[ryan_hurst]

A couple points:

There are a few trust models for OCSP signing; CA signed, CA Delegated, VA Signed and VA delegated. Both CA signed and CA Delegated are in use in WebPKI. The most common is CA Delegated where a OCSP responder has a certificate from an issuing CA with the OCSP EKU. CA Signed is also increasingly common because it saves sending one certificate significantly reducing the size of the OCSP response (from 2.5k to 470bytes in many cases).

There are also CAs that will not "start-up" if they do not have the OCSP signing EKU in them (The Microsoft one in particular) as the implementors believed it was mandatory (aka I shouldn't be a CA if I can't reliably revoke certificates). I am not aware of clients that require the CA to have the OCSP EKU to sign its own responses though but that is the behavior of at least the MS CA (I would change it if I could).

I don't think Mozilla should do anything to prevent CA signed responses from working; though wrongly implemented it puts the CA key online (which is bad) this design pattern is not strictly necessary; for example one can pre-produce OCSP good/revoked responses ever few minutes or hours and propagate them to edge servers that distribute them and have those edge servers sign unknown with CA delegated certificates cutting the size of the most common response size down to 470 bytes while still protecting the CA key from online attacks.

Comment 4

[Steve Roylance]

Hi all.  This issue was highlighted to the CABForum public mailing list at the time ballot 105 was being discussed back in July 2013.  Microsoft have logic in MSADCS requiring the presence of the EKU otherwise OCSP cannot be fully supported on the platform.   GlobalSign requested a modification from the Product Management team in Microsoft, however this was not accepted.  There should be a KB reference available to qualify the decision from Microsoft's perspective available soon.  I shall post it to the bug when available.  In the mean time all customers running Microsoft CA need to have this EKU.  EJBCA and Ascertia's platforms for example do not require the EKU and therefore it is not present in Subordinate Authority Certificates for these platforms.   GlobalSign is looking at alternatives and I have now forwarded this bug to the Microsoft team.

Comment 5

[Kathleen Wilson]

So, can we do this...

(From Comment #2)
> There is another way that we could/should prevent a certificate from being
> able to forge OCSP responses for itself: When verifying an OCSP response's
> signature, we could verify that the public key of the OCSP response signer
> is not equal to the public key of the certificate for which the OCSP
> response applies.

and allow intermediate certs to have the 'OCSP Signing' EKU?


If yes, is this something we'll want to change in the future?

Comment 6

[ryan_hurst]

Kathleen,

The key check would be a safe/interoperable way to prevent this risk and still allow the MS behavior to exist.

Comment 7

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Steve Roylance from comment #4)
> Hi all.  This issue was highlighted to the CABForum public mailing list at
> the time ballot 105 was being discussed back in July 2013.  Microsoft have
> logic in MSADCS requiring the presence of the EKU otherwise OCSP cannot be
> fully supported on the platform.   GlobalSign requested a modification from
> the Product Management team in Microsoft, however this was not accepted. 

Thanks Steve. I think you are referring to the messages I am partially quoting here:

https://cabforum.org/pipermail/public/2013-April/001419.html:

> > Rob Stradling wrote:
> > On 22/04/13 15:08, Erwann Abalea wrote:
> <snip>
> >> 12. Appendix B(2)G:
> >>        "id-kp-OCSPSigning MUST be present"
> >>
> >> Disagree.  The OCSP Signing trust purpose is not supposed to be passed
> >> down from the Root, and AFAIK there is no way to prevent a Subordinate
> >> CA from issuing delegated OCSP Signing Certificates!  (If you have
> >> evidence to the contrary, please say).
> >
> > I think the requirement is really a "id-kp-OCSPSigning MUST NOT be present".
> > If CA A issues a certificate to CA B with id-kp-OCSPSigning in the EKU,
> > then CA B has now a valid OCSP responder for certificates issued by CA
> > A; which is certainly NOT something wanted by CA A.
> 
> +1

As Rob noted above, there is another reason (besides the one I mentioned above) that it is UNSAFE for a sub-CA certificate to have the id-kp-OCSPSigning certificate. Consider two chains:

   EE-foo-1 <- Google Internet Authority <- Trusted Root
   EE-bar-1 <- Mozilla Internet Authority <- Trusted Root
   
If the "Mozilla Internet Authority" sub-CA certificate has the id-kp-OCSPSigning EKU, then it can forge OCSP responses for the "Mozilla Internet Authority" certificate (which just doesn't make sense) AND it can forge OCSP responses for the "Google Internet Authority" certificate. That's clearly and obviously bad.

(In reply to ryan_hurst from comment #3)
> There are also CAs that will not "start-up" if they do not have the OCSP
> signing EKU in them (The Microsoft one in particular) as the implementors
> believed it was mandatory (aka I shouldn't be a CA if I can't reliably
> revoke certificates). I am not aware of clients that require the CA to have
> the OCSP EKU to sign its own responses though but that is the behavior of at
> least the MS CA (I would change it if I could).

I agree that seems like a serious interop issue. But, I think it is more important to protect against one externally-operated sub-CA certificate from being able to forge OCSP responses for another externally-operated sub-CA certificate, than it is to work around Microsoft's bug.

> I don't think Mozilla should do anything to prevent CA signed responses from
> working;

I am not proposing that we bad direct signing--in fact, I advocated strongly for it in the last CABForum meeting for the same performance benefits you mentioned. The problem isn't that the sub-CA can sign OCSP responses for certificates it issues (direct signing). The problem is that the sub-CA could forge an OCSP response *for its own sub-CA cert*. That is, even if the root revoked the sub-CA certificate, the sub-CA could forge an OCSP response for itself that would effectively un-revoke itself. That's bad and I want to prevent that scenerio.

(In reply to Kathleen Wilson from comment #5)
> So, can we do this...
> 
> (From Comment #2)
> > There is another way that we could/should prevent a certificate from being
> > able to forge OCSP responses for itself: When verifying an OCSP response's
> > signature, we could verify that the public key of the OCSP response signer
> > is not equal to the public key of the certificate for which the OCSP
> > response applies.
> 
> and allow intermediate certs to have the 'OCSP Signing' EKU?

This protects against the "sub-CA can forge OCSP responses for itself" case. However, it wouldn't protect against the "Mozilla attacks Google" case I mentioned above. I think the "Mozilla attacks Google" case is equally important to defend against.

Comment 8

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

OK, more precisely, this is the check we do: If id-kp-OCSPSigning is present in the EKU field, then validation fails unless we're validating the cert as the signer of an OCSP response. The question is whether we can safely remove this check.

We already require delegated OCSP response signing certs to be end-entity certificates in pkixocsp.cpp:

  rv = CheckIssuerIndependentProperties(trustDomain, cert, time,
                                        MustBeEndEntity, 0,
                                        SEC_OID_OCSP_RESPONDER,
                                        SEC_OID_X509_ANY_POLICY, 0);

Thus, we already have another protection against the "Mozilla Internet Authority attacks Google Internet Authority" scenerio above and also we're protected against the "sub-CA certificate can sign OCSP responses for itself" scenerio. And, since we require the OCSP response signer to chain directly to the issuer cert, we protect against the "EE-bar-1 attacks Google Internet Authority" scenerio too.

Thus, it may indeed be the case that we can just remove the "If id-kp-OCSPSigning is present in the EKU field, then validation fails unless we're validating the cert as the signer of an OCSP response" check, replacing it with comments that describe what I said in the paragraphs above. What do others think?

Comment 9

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Attachment: patch

Comment 10

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Comment on attachment 8403583 [details] [diff] [review]
patch

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

::: security/pkix/lib/pkixcheck.cpp
@@ +426,5 @@
>      // When validating anything other than an delegated OCSP signing cert,
>      // reject any cert that also claims to be an OCSP responder, because such
>      // a cert does not make sense. For example, if an SSL certificate were to
>      // assert id-kp-OCSPSigning then it could sign OCSP responses for itself,
>      // if not for this check.

Please add a comment here such as this one (properly word wrapped):

That said, we accept CA certificates with id-kp-OCSPSigning because some CAs in Mozilla's CA program have issued such intermediate certificates, and because some CAs have reported that some Microsoft server software wrongly requires CA certificates to have id-kp-OCSPSigning. Allowing this exception does not cause any security issues because we require delegated OCSP response signing certificates to be end-entity certificates.

Comment 11

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Thanks for the quick review.
https://hg.mozilla.org/integration/mozilla-inbound/rev/cff54271a951

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/cff54271a951

Comment 13

[Steve Roylance]

Although this is resolved, here's the KB link from Microsoft which I promised to send through once available.  http://support.microsoft.com/kb/2962991  Thanks.