On 07/02/2015 07:10 PM, William A Rowe Jr wrote: > On Wed, Jul 1, 2015 at 8:54 AM, Plüm, Rüdiger, Vodafone Group > <ruediger.pl...@vodafone.com > <mailto:ruediger.pl...@vodafone.com>> wrote: > > > > -----Ursprüngliche Nachricht----- > > Von: benlau...@gmail.com <mailto:benlau...@gmail.com> > [mailto:benlau...@gmail.com <mailto:benlau...@gmail.com>] Im > Auftrag von > > Ben Laurie > > Gesendet: Mittwoch, 1. Juli 2015 14:27 > > An: dev@httpd.apache.org <mailto:dev@httpd.apache.org> > > Betreff: Re: [RFC] Enable OCSP Stapling by default in httpd trunk > > > > On 1 November 2014 at 09:05, Kaspar Brand <httpd-dev.2...@velox.ch > <mailto:httpd-dev.2...@velox.ch>> > > wrote: > > > On 30.10.2014 15:51, Jeff Trawick wrote: > > >> IMO the present concerns with OCSP Stapling are: > > >> > > >> * not so clear that it has seen enough real-world testing; commented > > out > > >> sample configs and better documentation will help, as will enabling > > by > > >> default in trunk (just a little?) > > >> * related bugs 57121 and 57131 > > >> > > >> A simple way to help with the broader issue raised in 57131, as well > > as fix > > >> 57121, is to not hold the global mutex while communicating with a > > >> responder, with other handshakes completing with the existing > > response in > > >> the cache as long as it is valid, or with the appropriate > > >> communication-error response otherwise (some details omitted ;) ). > > >> > > >> There are a few other bugs currently open for less severe issues. > > >> > > >> TIA for your comments! > > > > > > I'm -1 on this, under the assumption that 2.4.x would eventually also > > > turn it on by default (yes, I'm aware of PR 50740, and CABF trying to > > > push this). > > > > > > While enabling it by default on trunk probably doesn't change much > > (in > > > my experience, very, very few people really compile and run trunk, I > > > would even claim that this applies to http devs, too), I feel that > > the > > > approach of "let's turn it on by default and see how many people run > > > into problems" (and bring them up on httpd-users etc.) isn't right. > > > Those interested in achieving a more widespread use should > > specifically > > > test OCSP stapling with mod_ssl, report their findings, file PRs on > > > Bugzilla (and if possible, also submit suitable patches). > > > > > > The fundamental objection I have to enabling stapling by default in > > our > > > GA releases is that it would enable a "phoning home" feature (to the > > > CA's OCSP responders) as a side effect of configuring a certificate. > > > This is a setting I consider unacceptable for software published by > > the > > > Apache HTTP Server project - the default must be opt-in, not opt-out. > > > > I've just become aware of this objection and would like to understand > > the thinking behind it. Firstly, it seems strange to call this > > "phoning home", a term that _usually_ means connecting to the vendor > > of the s/w. > > > > But more importantly, what harm is there in a server connecting to the > > OCSP responders for the certificates it is serving? Why is this > > "unacceptable"? > > Because in many organizations it can't because of network / firewall > restrictions. > If it tries nevertheless by default this causes the following issues with > a default configuration: > > 1. As the network components / firewalls likely simply drop the packages > the TCP connect to the OCSP server needs to > run into TCP connection timeout which can take quite a while blocking the > response back to the client of the > webserver. Finding this out can be troublesome. > > 2. As the webserver will try to connect to the OCSP server quite often > and is denied this likely triggers intrusion > detection systems and starts all kind of security processes in an > organization that thinks that a hacked server > tries to connect to the outside world. > > > Although we are talking about large organizations... if they choose to > disable OCSP to their organization, isn't it > equally upon them to configure the server to ignore OCSP?
Just to be sure I don't miss anything. This is not about disabling OCSP, its about disabling OCSP stapling by default. Maybe I have a wrong understanding of OCSP stapling, but to me stapling only provides performance improvements, not security improvements for the client as the client still could connect to the OCSP URL given in the cert directly and get the answer from there. If the response is stabled it does not need to (with the same level of security) and saves itself a roundtrip to the OCSP server of the CA and the OCSP server of the CA a request to process. > > These are the same organization whose management are often those targeted by > malware anyways. It's on them if they > choose to ignore what few security measures are available to the less savvy > end user. Again I don't get what this has to do with malware attacks on these organizations, but maybe my understanding of OCSP stapling is entirely wrong. Regards Rüdiger
