[SSL Observatory] Diginotar broken arrow as a tour-de-force of PKI fail
Peter Gutmann
pgut001 at cs.auckland.ac.nz
Mon Sep 5 20:13:20 PDT 2011
Gervase Markham <gerv at mozilla.org> writes:
>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?
OCSP is much more broken than that. The following, from the ref. I mentioned
previously, hardly scratches the surface, but here it is for starters:
Because it was designed not as a new validity checking mechanism but as a
fully bug-compatible stand-in for CRLs, OCSP perpetuates many of the flaws
of offline CRLs onto the online world. For example many OCSP responders are
fed from CRLs (with the CRL acting as the DNS zone transfer mentioned
earlier), providing the illusion of online operation while fully preserving
the non- timeliness of CRLs. In fact OCSP extends the .accuracy. vs.
.consistency. debate in CRLs even further by providing even more dates and
times to be ambiguous over. Depending on whose responder you.re
communicating with, you may get an invalidity date corresponding to the time
that the revocation was requested, the time that the CRL was created, the
time it was published and/or received by the responder, or the time that the
OCSP response was created. In addition the validity time of the OCSP
information can be set more or less arbitrarily, from the full duration of
the CRL down to zero on the assumption that if the client wants a response
at a later time then they need to ask again (since the client doesn.t know
about this reasoning, some applications will look at the zero-validity
response, discard it as invalid, and proceed under the assumption that all
is OK).
Particularly amusing are the cases where the responder consults a week-old
CRL and then generates a response that appears to contain up-to-the-minute
status information. On the other hand the reverse can also happen, in some
cases CAs will pre-generate CRLs so that fetching revocation information via
a CRL will provide fresher information than performing the check via OCSP [
]. All of these cases are valid interpretations of the standard, which
leaves it up to implementers to decide exactly how they want to interpret
and communicate status-related information.
OCSP.s major shortcoming though is that instead of providing a simple yes/no
response to a validity query it uses multiple non-orthogonal certificate
status values because a blacklist-based system can.t provide a truly
definitive answer. The possible responses to a query are .not-revoked.
(confusingly labelled .good. in the OCSP specification), .revoked., and
.unknown., where .not revoked. doesn.t necessarily mean .OK. and .unknown.
could mean anything from .this certificate was never issued. to .it was
issued but I couldn.t find a CRL for it. (this issue was already
acknowledged as being a serious problem when OCSP was still in the draft
stage, but even now more than a decade after it was published the issue is
still deemed to be out of scope for correction [ ]). This leads to the
peculiar situation of a mechanism labelled an online certificate status
protocol that, if asked .Is this a valid certificate. and fed a freshly-
issued certificate can.t say .yes., and if fed an Excel spreadsheet or an
MPEG of a cat, can.t say .no.. Contrast this with another online status
protocol in use for the last couple of decades, credit card authorisation,
for which the returned status information is a straightforward .Authorised.
or .Declined. (with an optional side order of reasons as to why it was
declined).
This vagueness is the fault of the original CRL-based certificate status
mechanism that OCSP is built on because a CRL can only provide a negative
result, so that the fact that a certificate isn.t present in a CRL doesn.t
mean that it was ever issued or is still valid. For some OCSP
implementations the .I couldn.t find a CRL. response may be reported as .not
revoked/good., or will be interpreted as .good. by relying parties since
it.s not the same as .revoked. which is assumed to be .not good. (opinions
on the exact semantics of the responses vary somewhat among implementers
and, by extension, among actual implementations).
Another problem with OCSP is that it makes the (unfortunately all-too-
common) mistake discussed in .Cryptography for Integrity Protection. on page
271 of authenticating the response body but not the metadata surrounding it,
so that by manipulating the unprotected metadata an attacker can defeat the
protocol. As the paper in which this attack was presented points out, .most
OCSP implementations will accept this response without generating any kind
of warning to the user that something might be amiss, thus defeating the
protocol. [ ].
An even simpler attack on OCSP doesn.t even require knowledge of how OCSP
works. This can be implemented using nothing more than an HTTP proxy that
returns a 500 error to the client. Since most OCSP clients soft-fail when
they encounter errors (if they didn.t then any problem with the OCSP server
or the server.s connectivity would cause an outage of any site whose
certificate relied on it, see .Case Study: Inability to Connect to a
Required Server. on page 404 for details), the result nicely sidesteps OCSP
without requiring an attack on the protocol itself [ ].
This disagreement over how OCSP is supposed to work extends to the protocol
as a whole, to the extent that more than even today, more than ten years
after the original specification was published there is still strong
disagreement among implementers as to how certain aspects of it are supposed
to be interpreted [ ], with a browser security architect commenting that
.Mozilla has found it necessary to reject or indefinitely postpone at least
one request [for CA inclusion in the browser] per year because NONE of the
OCSP responses [.] could be determined to [conform to the OCSP
specification]. In each and every case, the CA organization had already
invested a large amount in its OCSP infrastructure, and its designers
believed that they were compliant with [the specification]. [ ].
The fundamental problem with blacklist-based approaches such as CRLs and
OCSP is that they ask entirely the wrong question, .Has this been revoked?.,
when in fact what.s required is an answer to the question .Is this currently
valid?. (OCSP was in fact explicitly intended not to function as a
certificate status protocol capable of answering this question [ ]).
Blacklist-based checks like CRLs and OCSP represent a fundamentally
dysfunctional approach to validity checking since they constitute a case of
.enumerating badness., No.2 in the Dumbest Ideas in Computer Security that
have already featured in .Mental Models of Security. on page 125. This
problem is not something that can be easily fixed, because that.s the only
question that a blacklist is capable of answering.
This problem is exacerbated even further by the way that OCSP identifies the
certificates to be checked. Rather than using a standard way of identifying
certificates, OCSP invented its own peculiar identifier that picks bits and
pieces out of the certificate, hashes some, doesn.t hash others, and then
combines them all into an untidy mess that gets submitted to the server. If
an implementation gets even one single bit out of place, the resulting
identifier will never match anything on the blacklist, and so the
certificate will never be reported as revoked. Since this type of failure
is completely silent (things appear to work just fine if the client and/or
server get the identifier wrong), some implementations have run for years
with incorrect identifiers, going through the motions of performing a
revocation check without actually doing so (in at least one case when this
problem was reported the organisation running the system decided that it
would be too problematic to change things and left everything as it was,
with a meaningless revocation check taking place at regular intervals). In
contrast a whitelist-based approach would never run into this problem
because the fact that every single certificate check was failing would be
quickly noticed and corrected.
This use of an identifier that doesn.t actually identify an entire
certificate but only a few isolated fields in it means that even if the
protocol was updated to provide a true valid/not-valid response, an attacker
could still trivially defeat it by creating a certificate with the same two
fields as a still-valid certificate, and the responder would report it as
valid because no other part of the certificate is used in the check.
[and so on and so forth]
Not meant as a criticism of Gerv or anything here, but I am kinda surprised
that people aren't aware of all this. OCSP was created as an expression of
X.509 dogma, not as any effective validity-checking mechanisms.
Peter.
More information about the Observatory
mailing list