httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Date Tue, 01 Sep 2015 23:54:22 GMT
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 

> 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 
>> 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 

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]

View raw message