489557 - OCSP Response signature cert validation regression

Status: RESOLVED INVALID

(NSS :: Libraries, defect)

Description

[Rob Stradling]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10pre) Gecko/2009042207 GranParadiso/3.0.10pre
Build Identifier: trunk

See below.

Reproducible: Always

Steps to Reproduce:
1. Tick "When an OCSP server connection fails, treat the certificate as invalid".
2. Clear out the "Software Security Device"s from the Certificate Manager.
3. Browse to https://forums.comodo.com.
Actual Results:  
Firefox 3.0.8 / Firefox CVS (3.0.10pre) + NSS HEAD:
  The URL can be reached successfully.

mozilla-1.9.1 / mozilla-central:
  sec_error_ocsp_invalid_signing_cert.

NSS_ENABLE_PKIX_VERIFY=1 for mozilla-1.9.1 / mozilla-central:
  sec_error_revoked_certificate.

Expected Results:  
No sec_error_* errors should be occurring, because the OCSP Signing Certificate and all other applicable certificates are valid and unrevoked.

This bug may well be a partial duplicate of some other bug(s).  479508 perhaps?

What I think makes this bug unique is that it describes a bug that doesn't also occur with FF3.0.x.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Rob, 

I suspect that this is a duplicate of your bug 485155.  Since you are 
able to build the NSS trunk and test Firefox with it, let me ask you to do 
that, and see if you can reproduce this bug with that.   If not, then I 
think that confirms this as a duplicate.

When a CA cert in the chain of a server's cert is revoked, NSS reports that 
the cert being tested (the server's cert) has an unknown issuer because NSS 
cannot find a valid issuer for some cert in the chain.  When this happens in 
the chain for the cert for the signer of an OCSP signature or CRL signature,
NSS reports that the server cert (whose revocation is being checked) is 
revoked, because the signature on the revocation info cannot be verified.

Now, perhaps you're suggesting that an OCSP response (or CRL) with an unverifiable signature should be treated the same as if NSS had been unable 
to reach the OCSP responder (or CRL server) at all.  Is that really what 
this bug is about?   If so, THAT is not a regression.  That's old behavior
and as expected, I believe.  You could request that it be changed.  It might
be best to discuss this in one of the relevant newsgroups first.

Comment 2

[Rob Stradling]

In reply to comment #1:
> Since you are able to build the NSS trunk and test Firefox with it, let me ask
> you to do that, and see if you can reproduce this bug with that.

I know how to build the Firefox 3.0.x CVS code with NSS trunk.  I did this yesterday and (as I said in the Description of this bug) this bug did not occur with it.

I don't know how to checkout/build mozilla-1.9.1 or mozilla-central with NSS trunk.  I think this is what you're asking me to do.
What is a/the good/correct/best way to do this?

> When a CA cert in the chain of a server's cert is revoked...

This bug is not about what NSS does when it encounters a certificate that is revoked.  No revoked certs appear in the certificate chain served by https://forums.comodo.com, and no revoked certificates appear in the certificate chains of the OCSP Responses.

> Now, perhaps you're suggesting that an OCSP response (or CRL) with an
> unverifiable signature...

I am saying that all of the server cert chain signatures and OCSP Response signatures are verifiable, and that for mozilla-1.9.1 and mozilla-central to fail to verify them is a bug.
Furthermore, since this bug does not occur with either Firefox 3.0.8 or Firefox 3.0.x CVS, I am calling this a regression.

And I don't want to see this regression sneak into Firefox 3.5 and affect real users. :-)

> ...should be treated the same as if NSS had been unable to reach the OCSP
> responder (or CRL server) at all.

I am not saying that.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

> I know how to build the Firefox 3.0.x CVS code with NSS trunk. 

OK, do that.  I didn't mean to ask you to try a different browser code base 
than before.  I meant to ask you to do again what you've done before, with 
the latest NSS trunk code.

Comment 4

[Rob Stradling]

I've just built the very latest FF3.0.x CVS code with NSS trunk.  I can navigate to https://forums.comodo.com without any sec_error_* errors occurring.  I get the same result with NSS_ENABLE_PKIX_VERIFY=1.

This is the behaviour I expected to see.  As I wrote in the Description of this bug, I have only encountered this bug with mozilla-1.9.1 and mozilla-central (both with and without NSS_ENABLE_PKIX_VERIFY=1).

Nelson, I'm wondering if your previous comments are trying to hint that this might be a PSM bug in mozilla-1.9.1/mozilla-central rather than an NSS bug.  Is this the case?

Comment 5

[Kaspar]

(In reply to comment #4)
> I have only encountered this bug with mozilla-1.9.1 and mozilla-central
> (both with and without NSS_ENABLE_PKIX_VERIFY=1).

Both hg repositories have their own, "independent" snapshots of NSS. mozilla-1.9.1 is currently at 3.12.3 (see bug 481968), and mozilla-central has NSS_3_12_3_BETA2 (bug 473837).

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Rob, I went back today and re-read this entire bug more carefully, and have
returned to the conclusion I had in comment 1, but with slightly different
reasoning.  

I believe that this bug is a duplicate of your bug 485155.  That is, the two
bugs have the same underlying cause.  That problem is present in NSS 3.12.3, 
but has already subsequently been fixed in NSS HEAD, as you observed in 
comment 0.  

(Somehow I missed the presence of the word HEAD when I first read that description.  I now realize that the test I asked you to do in comment 3 was
effectively asking you to repeat the test you had already done and reported
in comment 0.  I apologize for that. Had I noticed that, I would not have 
asked you to repeat it.)

The problem is present in "mozilla-1.9.1 / mozilla-central" because those 
are using NSS 3.12.3 (IINM) which does not have the fix.  I hope sincerely
that Firefox will update to 3.12.4 RTM for FF 3.5 RTM.  

Here's something you can do to test my theory (about this being a duplicate)
without having to build from Hg sources yourself.  It's the very thing that 
I do to test NSS trunk against versions of FF that are built from Hg sources.

In short: After installing a Firefox version that was built from Hg, such as
the one(s) you described as "mozilla-1.9.1 / mozilla-central", backup the NSS 
shared libraries that were installed with it, and then replace them with the 
NSS shared libraries from your own NSS HEAD build. Then, when you run that 
Firefox, you will be testing FF as if it had been built with NSS HEAD.

Specifically, copy these files from your own build:
freebl3.chk
freebl3.dll
nss3.dll
nssckbi.dll
nssdbm3.chk
nssdbm3.dll
nssutil3.dll
smime3.dll
softokn3.chk
softokn3.dll
ssl3.dll

You may also copy the .pdb files correspnding to the above .dll files, if 
you have them and wish to use them for debugging in Firefox.

Do NOT copy sqlite3.dll.  Firefox won't run with NSS's build of that file 
for reasons unknown to me, but NSS is quite happy with Firefox's build of 
that file.  So leave Firefox's build of that file in place.

If you do that test, and are satisfied that you cannot reproduce this problem
with that combination of files, then I think that confirms my hypothesis that
this is a duplicate.

Comment 7

[Rob Stradling]

Nelson, I run Linux rather than Windows, so I've changed the .so/.chk symlinks instead of copying the .dll/.chk files.  This seems to have had the desired effect (I checked the /proc/<pid>/maps file for the firefox-bin process).

However, this bug still occurred, which suggests that it is not a duplicate of bug 485155.
Also, I think it's worth noting that Bug 485155 only occurs when NSS_ENABLE_PKIX_VERIFY=1 is set, whereas this bug only occurs when mozilla-1.9.1 or mozilla-central are used.

Might bug #479508 be relevant (as I suggested in the Description)?
Might this be a PSM bug in mozilla-1.9.1 / mozilla-central (as I suggested in comment #4)?

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Rob, I did 3 tests:
a) FF 3.0.10 + NSS HEAD
b) Minefield + NSS HEAD
c) Minefield + NSS HEAD + NSS_ENABLE_PKIX_VERIFY=1 
and I got the same results you reported in comment 0. 
This is puzzling, to say the least. 
If it was a bug in NSS HEAD, I would expect it would affect all 3 of those
tests, but only two are affected.  I will investigate.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Ok, mystery solved.  This is an unintended NSS behavior present in the trunk.  
However, It's not yet clear to me whether this is an NSS bug or a fault of 
the OCSP responder.  

The reason that this bug only occurs in minefield, and not in FF 3.0.x,
is that only Minefield has your callback function that supplies an OCSP URL
in place of a CRL DP URL.  But I don't mean to put any blame on that callback.  It's doing fine. 

The existence of that callback causes some certs to get OCSP checked in 
Minefield, but not in FF 3.0.x.  One of those certs is the CA cert that is 
used to sign the OCSP response for the OCSP query for forums.comodo.com.  
When we go to verify the OCSP responder's cert, the callback supplies an 
OCSP URL, and so NSS tries to do an OCSP check on the CA cert that is the 
response signer, we get back an OCSP response that says "Unauthorized request".  

Now, I know that, in general, we should not be doing OCSP checks on OCSP
responder certs.  We don't for designated responders that are not CAs, 
but we do for OCSP responders that are CAs.  

But when we ask the OCSP responder for an OCSP response on the status of 
that CA cert, the responder cannot know that this request is being done
to verify an OCSP response.  AFAIK, It cannot tell the difference between 
that and an OCSP request to merely verify the freshness of a CA cert in a 
chain.  So, I think it is probably wrong for the OCSP responder to return 
"unauthorized request" for our OCSP query on that CA cert.  To put it 
another way, if it reports "unauthorized request" when we ask about that 
CA cert as an OCSP responder, then it will also return that when we ask 
about that CA cert as an ordinary chain member.  To put it yet another way,
the OCSP responder is effectively saying that the CA that issued the SSL 
server's cert is revoked or expired.  And that is what Minefield reports.

I need to think about this some more, but presently, it looks to me like 
this is BOTH a bug in the OCSP responder's response, AND in NSS.  I think
that it will be necessary for Comodo's OCSP responder to return different
responses for that CA cert for OCSP to work.

Comment 10

[Rob Stradling]

In reply to comment #9:
> The reason that this bug only occurs in minefield, and not in FF
> 3.0.x...is...your callback function...and...an OCSP check on the CA cert.

Ah, of course.  I'd been assuming that the problem must be related to the OCSP checking of the end-entity cert.  I'd forgotten that Shiretoko/Minefield now do OCSP checking for Intermediate CA certs too.

> we get back an OCSP response that says "Unauthorized request". 
> ...
> I think that it will be necessary for Comodo's OCSP responder to return
> different responses for that CA cert for OCSP to work.

Good catch!  Thank you very much for spotting this.

I've just fixed Comodo's OCSP responder so that it does now return a valid "good" OCSP response for that particular Intermediate CA cert, and I can now no longer reproduce any of the problems from comment 0.  :-)

Do you want to mark this bug as INVALID now?
Or do you still think that there might be new NSS bug(s) here too?

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

Thanks for fixing that, Rob.  I'm going to mark this invalid.
I may file an additional NSS bug about verification of OCSP responder certs.