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 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 don't know why you think your example shows that - 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). This is why browsers are pushing for OCSP stapling, not because of speed. Certificate Transparency faces the same problem, which is why it only exists as an in-band mechanism. 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. Leaving it to admins makes no sense to me - most admins are not acquainted with the detailed reasons for/against stapling, and are not in a position to make an informed decision. Someone has to choose the default, and IMO the ASF should always default to "more secure". > > 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 >
