-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
