[SSL Observatory] State of SSL-brokenness: Google wants to disable CRL/OCSP

[Peter Gutmann]

Hanno =?ISO-8859-1?B?QvZjaw==?= <hanno at hboeck.de> writes:

>Seems google noted that using OCSP and not rejecting certificates on
>connection failure doesn't make much sense:
>http://www.imperialviolet.org/2012/02/05/crlsets.html
>
>So they decided that they'll probably disable OCSP altogether. Not sure what
>I should think of it (seriously, they're probably right to disable something
>that is broken anyway).

Good to see some common sense finally prevailing in this.  I did a lengthy
analysis of it some time ago:

  What the addition of [OCSP] has done is make the system considerably more
  brittle, reducing its reliability to the lowest common denominator of the
  web server and the OCSP server, as shown in Figure 123.  Recognising this,
  both MSIE 7 and Opera 9 allowed a connection to a site if the corresponding
  OCSP server couldn.t be contacted while Firefox 2 disallowed the connection
  with an incomprehensible OCSP error message. Predictably, the OCSP error was
  seen by users to mean that the site was down, leading to OCSP-induced
  apparent outages of major services like FedEx [ ] .  Mozilla later changed
  Firefox. behaviour to ignore problems that occurred when communicating with
  OCSP responders, acknowledging the fact that .breaking web sites because of
  the unreliability of an OCSP responder is worse [than any security
  consequences]. [ ].

  While we.ve learned to make web servers extremely reliable, we haven.t yet
  done the same for OCSP servers (not helped by the fact that at the time of
  writing no major CA appears to provide for backup OCSP servers in its
  certificates, making the sole OCSP server the single point of failure no
  matter how replicated and redundant the web server or other resource that
  it.s required for might be), and it.s unlikely that there.ll ever be much
  evolutionary pressure to give them the same level of reliability and
  performance that web servers enjoy.  In fact things seem to be going very
  much in the opposite direction: since the OCSP protocol is inherently non-
  scalable, a recent performance .enhancement. was to remove protection
  against man-in-the-middle attacks, making it possible for a server (or an
  attacker) to replay an old response instead of having to generate a new one
  that reflects the true state of the certificate [ ].

(that's just a portion of it) which concluded that it had, at best, a 
questionable impact on security, but a very measurable negative impact on 
availability.  So what Google has done makes perfect sense.  As Ian Grigg put 
it during the Diginotar meltdown, "revocation only works when you don't need 
it".

Peter.