[SSL Observatory] Diginotar broken arrow as a tour-de-force of PKI fail

[Jacob Appelbaum]

On 09/05/2011 11:40 AM, Gervase Markham wrote:
> On 05/09/11 10:34, Martin Rublik wrote:
>> There are implementations of OCSP responders that use CRL as an input for
>> determining whether certificate is valid or not.
> 
> So if the cert is not in the CRL, they assume it's valid?
> 
> http://www.ietf.org/rfc/rfc2560.txt :
> "   The "good" state indicates a positive response to the status inquiry.
>    At a minimum, this positive response indicates that the certificate
>    is not revoked, but does not necessarily mean that the certificate
>    was ever issued or that the time at which the response was produced
>    is within the certificate's validity interval."
> 
> Wow, that sucks. I mean, clients should check expiry, but the
> possibility of returning "good" for non-existent certificates is just
> totally broken.
> 
> Then again:
> 
>    "The "unknown" state indicates that the responder doesn't know about
>    the certificate being requested."
> 
> You would hope the responder would at least return that!

An interesting problem here is that even if OCSP worked... it doesn't
appear that browsers want people to use this feature generally.

In Firefox, I see:
security.OCSP.enabled and it is set to 1.
security.OCSP.require and it is set to false.

So it's on but it's not a hard fail?

Ironically, I also see:
services.sync.prefs.sync.security.OCSP.enabled and it is set to true.
services.sync.prefs.sync.security.OCSP.require and it is set to true.

It looks like the CA that runs Mozilla's OCSP server probably gets a
record of all people that use sync unless you guys use OCSP stapling.

So, I guess the reason not to enable it is merely that it might fail
closed and deny access when it's not really a MITM? Is there some other
reason? Surely it isn't ... privacy? The privacy baby is already out
with the bathwater there... Can we have some security with that privacy
violation to at least make it a worthwhile trade off?

All the best,
Jacob