On 08/30/2015 02:30 AM, Kaspar Brand wrote:
On 28.08.2015 19:27, Jeff Trawick wrote:
For one, it is appropriate for the default config is there to enable
practices which are reasonable in most situations, and OCSP Stapling is
widely accepted as an appropriate feature for HTTP servers to enable.
I have some doubts whether "widely accepted" is an accurate summary of
today's situation, because this assessment misses the fact that with the
current RFC-6066-based implementation, stapling can't fully achieve the
goal of obviating OCSP queries for the clients - all publicly trusted
CAs use hierarchies with at least two tiers these days, so effectively
RFC 6961 support would be needed.
I plead ignorance, but I don't see that "can't fully achieve" is a blocker.
And given that the most popular
browser only enforces revocation checking for EV certificates (certainly
less than 10% of all SSL certs out there), the benefit of turning on
stapling for DV/OV certs by default is not so apparent either.
Is there a synopsis of which browsers support it for which types of
certificates?
What wasn't mentioned in the original RFC [1], and what I'm still
wondering about, is the primary motivation for enabling it on trunk?
The motivation for putting it in trunk is so that the next release has
stapling enabled in the default configurations, which essentially means
that in some number of years (2-3? I dunno) there will be a
faster-growing number of httpd instances that have OCSP stapling enabled.
Admins can of course enable it now, but people don't bother until
something like SSLLabs starts dinging configurations that don't have it on.
As
I wrote in my reply at that time, changing the default in trunk will
hardly help in getting broader real-world testing results.
For now, it hardly helps. As we approach a release and start talking
about it and having alphas and betas, it helps a lot more because more
than the same 20 people are trying it out.
If the
plan is to propose a backport to 2.4.x soon afterwards, however, then I
would certainly oppose unless systematic coverage for OCSP stapling is
added to the test framework (enabling a feature by default in a GA
release for which there is not a single test is a no go, IMO).
The point about adding tests is good.
I find this 2.4.x tangent disorienting, but maybe that's just me. (And
even if 2.4.x default configs were changed, it would affect hardly
anyone. The people who build from source and just start using the
latest configs every time probably aren't in control of many aspects of
their system anyway. Building and installing the normal way leaves you
with the same configuration.)
Part of what makes the 2.4.x tangent is confusing is that sometimes your
objections seem to be qualified on the assumption that 2.4.x would be
updated. Can we please drop 2.4.x from this conversation?
Also, strictly speaking, the default config does not have SSL enabled
anyway, and after manually enabling it OCSP responses won't be fetched
unless a certificate is configured which references an OCSP responder.
It should be worth mentioning that the OCSP URI in a server cert is to
be considered untrusted, as mod_ssl does not validate its own cert at
startup.
I would think that the problem is if the hostname doesn't point where it
is supposed to point, so the I/O can't be allowed to stall and mod_ssl
and OpenSSL have to avoid assuming the data is well-formed. Besides
that, the admin and the browser own the rest.
It's also for this reason that I'm not in favor of a global
"SSLUseStapling On", it should really be configured on a per-vhost basis.
I don't follow. What does that help? With which attack vector does
that improve the situation?
While I find the "not make accidental outgoing connections" argument
compelling (though perhaps with a different word than "accidental") the
server already takes actions that cause outgoing connections to services
not explicitly configured (DNS), and these occasionally cause problems.
Are you referring to queries when doing PTR lookups for connecting
clients? I think that's one of the very reasons why "HostnameLookups
Off" was chosen for extra/httpd-default.conf.
Not HostnameLookups; resolving ServerName at startup (configured or
defaulted).
Is there a principle at stake which could be followed consistently across
disparate features in how the server behaves a) with compiled in defaults
and minimal config, or b) with default/recommended config?
The default configuration should not trigger unsolicited outgoing
queries to untrusted systems, for both a) and b), that's how I would
put it.
Admin configures a certificate that has a domain name of attacker in the
responder URI? DNS entry for domain name in responder URI is taken over
to point to attacker?
Additionally, features enabled by default need to have sufficient
coverage in the test framework.
Coverage in the test framework is obviously a very good thing.
Is it your understanding that this high bar to enabling behavior in
trunk without explicit configuration is currently followed for most such
changes?
So forgetting 2.4.x, are you vetoing changing the trunk default config
to enable stapling, and are the criteria of the veto both
1. The default configuration should not trigger unsolicited outgoing
queries to untrusted systems, for both a) and b), that's how I would put it.
2. Additionally, features enabled by default need to have sufficient
coverage in the test framework.
If enabling stapling were more closely tied in the configuration language
to configuring a certificate, which with "SSLUseStapling On" is the user
action that makes mod_ssl talk to a responder, would that help the end
user? (Controlling stapling parameters on a per-certificate basis is
valuable anyway since you can have multiple certificates per vhost,
possibly with different responders.)
It's not very common to configure multiple certs for a single vhost, I
guess - mainly due to the single-chain-only limitation in OpenSSL up to
1.0.1. I wouldn't put too much effort into making it a per-certificate
setting (seems relatively complex to implement, at least at first glance).
Kaspar
[1]
https://mail-archives.apache.org/mod_mbox/httpd-dev/201410.mbox/%3CCAKUrXK6k01WGqF8z6F3YBNbanbTaOSHbbzwSi2O3H3u03_mvUw%40mail.gmail.com%3E
