httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Date Thu, 02 Jul 2015 18:03:29 GMT


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.pluem@vodafone.com
> <mailto:ruediger.pluem@vodafone.com>> wrote:
> 
> 
>     > -----Ursprüngliche Nachricht-----
>     > Von: benlaurie@gmail.com <mailto:benlaurie@gmail.com> [mailto:benlaurie@gmail.com
<mailto:benlaurie@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.2014@velox.ch <mailto:httpd-dev.2014@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



Mime
View raw message