[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