On 5 Sep 2015, at 11:53, Ben Laurie <b...@links.org> wrote: > On Sat, 5 Sep 2015 at 09:32 Kaspar Brand <httpd-dev.2...@velox.ch> wrote: >> On 04.09.2015 17:54, Rob Stradling wrote: >>> Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling >>> enabled. Browsers aren't likely to start hard-failing by default until >>> that % is a lot higher. > > …the reason browsers don't hard fail is because OCSP (or any out of band > communication) is unreliable. So that either means you fail for sites that > are actually perfectly OK, or you allow an attacker to override revocation > (by blocking OCSP). … > Blocking stapling (and presumably you will also object to CT for similar > reasons) is hurting security. > > You've argued that there's no point switching on stapling because browsers > won't pay attention to OCSP anyway. That is not true. They don't pay > attention to OCSP because it is unreliable. If stapling were widely deployed, > then it would be possible to switch on hard fail.
It's not just conventional browsers. I think automated / embedded HTTP clients will also benefit from stapling, either because networking filters would block a conversation between the client and the CA's OCSP responder, or the extra latency from using conventional OCSP is a problem. For another example of a non-interactive application implementing OCSP, look at the Exim mail transfer agent (which can be both client and server). -- Tim Bannister – is...@c8h10n4o2.org.uk
