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 vast majority of the servers that have OCSP stapling enabled are > running IIS. I claim that this is due to the fact that IIS enables OCSP > stapling by default.
The relevant metric is the percentage of (initial) TLS handshakes with stapled responses, not so much the percentage of servers with stapling enabled. Judging from Mozilla's telemetry data for Firefox 39 and 40, that percentage is still below 15%, and enabling stapling in an httpd config file which gets used by a very small number of Apache httpd admins (as opposed to those settings which go out to the world via [1] or [2]) doesn't look like a very effective way of achieving the goal of making that percentage "a lot higher". I'm also very sceptical that a higher percentage of handshakes with stapled responses (how much exactly?) will lead browser vendors to switch to hard fail - as the test-sspev.verisign.com example from my previous message shows, they could do this for EV today already (even Chrome tries querying the OCSP responder in this case). But none of them does, often due to the fear of losing market share when being too strict in enforcing TLS security (cf. the case of RC4 banning). > I think you've misunderstood the "speed, speed, speed" argument. > > If an OCSP response is delivered via stapling, then there's no need for > the browser to block the TLS handshake whilst it obtains an OCSP > response directly from the CA's OCSP responder. No, I didn't misunderstand. That's very much the essence of the "speed, speed, speed" argument - "our browser must be able to complete every TLS handshake in under 100 ms"... even if for a specific server, it's just one TLS handshake per day where it really matters. > Stapling provides a noticeable speedup even if the browser never caches > OCSP responses. Fairly hypothetical point - I'm not aware of any common browser which would use a cert validation library without an OCSP cache. Kaspar [1] https://git.centos.org/blob/rpms!httpd.git/c7/SOURCES!ssl.conf [2] https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/apache2/trusty/view/head:/debian/config-dir/sites-available/default-ssl
