On 05.09.2015 12:53, Ben Laurie wrote: > On Sat, 5 Sep 2015 at 09:32 Kaspar Brand <httpd-dev.2...@velox.ch> wrote: >> 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.
Unreliable in what sense, or for what reason? Due to OCSP responders being unreachable, being unable to handle the load, serving flawed responses (like the recent hiccup mentioned in https://twitter.com/GSSystemAlerts/status/634418637835669504), or...? Only the second point can be addressed by stapling, as it simply switches to another method for transmitting the response to the client. > 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. Taking into account that OCSP responders from the big players are running on fairly robust infrastructure these days (cf. the sr.symcd.com example, aka ocsp.verisign.net, aka ocsp.ws.symantec.com.edgekey.net), I'm not buying the "OCSP is unreliable" statement in this wholesale form. Even assuming that, say, 90% of all handshakes would include stapled responses one day, I'm pretty sure that browsers would come up with other arguments as to why they can't enforce hard-fail. Or perhaps in one or two years, they want everybody to switch to using short-lived certs without OCSP (because "revocation doesn't work" anyway), at which point the "let's get OCSP stapling universally deployed" exercise would become moot. > 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. CT is a completely separate topic, but for the sake of completeness: yes, I would object to enabling such a feature in httpd by default, as long as it triggers outgoing connections on the server. That isn't the case for being able to serve SCTs, however: all it takes is httpd/mod_ssl 2.4.8 or later compiled against OpenSSL 1.0.2a or later, an appropriate "BEGIN SERVERINFO FOR..." file and an "SSLOpenSSLConfCmd ServerInfoFile ..." directive in the config (no outgoing connectivity on the server needed, neither permanently nor temporarily). > 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. Again, the "OCSP is unreliable" statement is just your current claim (unless you can provide real-world measurements showing things like "30% of all OCSP queries fail due to timeouts", "50% of all OCSP checks take more than 3 seconds" or similar). Having used Firefox with security.OCSP.require=true for extended periods of time, I do not agree with the overall assessment of OCSP being unreliable. > 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. That's what our documentation is for. Just asserting that admins are too dumb to understand and instead decide on their behalf is an attitude I strongly dislike. Apache httpd is not the same sort of software like browsers for the big (and probably often clueless) masses, where that approach might have its justification. > Someone has to choose the default, and IMO > the ASF should always default to "more secure". Pretty muddy ground - "more secure" in what sense exactly? A server not being dependent on outgoing connectivity for its day-to-day operations is typically more secure than one which regularly needs to fetch data from the outside world. And if stapling is really making servers "more secure", why are www.google.com, mail.google.com or drive.google.com still not providing stapled responses as of today? (same is true for other high-traffic sites like Twitter or FB, JFTR) Kaspar
