Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
From: Kaspar Brand <httpd-dev.2014@velox.ch>
Subject: Re: [RFC] Enable OCSP Stapling by default in httpd trunk
To: dev@httpd.apache.org
References: 
 <CAKUrXK6k01WGqF8z6F3YBNbanbTaOSHbbzwSi2O3H3u03_mvUw@mail.gmail.com>
 <5454A244.6070006@velox.ch>
 <CAG5KPzypCfJ7rZVBSC6t2hqxV5=zJcBDRcQxrGVUmnuYAsU_mw@mail.gmail.com>
 <55A12E9C.6060805@velox.ch>
 <CACsi251vkwFs3Neqqf-cdF7W=WDZFGqY-L+1baWQdTfJ+OaZ6Q@mail.gmail.com>
 <55A363EC.6030801@apache.org>
 <CAKUrXK6m6BGhhP3fg_Gx9wFyWD8YV4PgmyRqMa7iv6bRLXMspw@mail.gmail.com>
 <55E2A31E.5000204@velox.ch> <55E63AAE.1010205@gmail.com>
 <55E9B1BB.3000005@velox.ch> <55E9BE99.8020508@comodo.com>
 <55EAA877.5090104@velox.ch>
 <CAG5KPzz=tW4i+PBT-UuHcdsn+RTmvFrkcsBaQ2ZMp0ZKqV+60A@mail.gmail.com>
Message-ID: <55EC3A5D.303@velox.ch>
Date: Sun, 6 Sep 2015 15:06:37 +0200
MIME-Version: 1.0
In-Reply-To: 
 <CAG5KPzz=tW4i+PBT-UuHcdsn+RTmvFrkcsBaQ2ZMp0ZKqV+60A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 05.09.2015 12:53, Ben Laurie wrote:
> On Sat, 5 Sep 2015 at 09:32 Kaspar Brand <httpd-dev.2014@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