Hanno =?ISO-8859-1?B?QvZjaw==?= <[email protected]> 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.
