> -----Ursprüngliche Nachricht----- > Von: benlau...@gmail.com [mailto:benlau...@gmail.com] Im Auftrag von > Ben Laurie > Gesendet: Mittwoch, 1. Juli 2015 14:27 > An: 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> > 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. Regards Rüdiger
