You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@gmail.com> on 2015/08/28 19:27:42 UTC
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On Mon, Jul 13, 2015 at 3:08 AM, Ruediger Pluem <rp...@apache.org> wrote:
>
>
> On 07/11/2015 08:55 PM, William A Rowe Jr wrote:
>
> > If you are suggesting we shouldn't change the compiled-in default, I can
> > agree, POLS (Principal Of Least Surprise). If you are suggesting the
> default
> > config shouldn't reflect the ability to efficiently handle OCSP by
> stapling, here
> > I think we would disagree.
>
> This something I can agree with: Leave the default compiled in to off and
> in the configuration distributed by us have it
> set to on.
>
> Regards
>
> Rüdiger
>
>
As of now there's still a veto on my suggestion of enabling stapling by
default in the httpd trunk config. Of Kaspar's justifications, I think
this is the text that remains of his clarifying post on July 11, ignoring
the license reference:
"a) by default, an HTTP server is supposed to process *incoming* requests,
not make accidental outgoing connections in addition (at least not unless
it's explicitly instructed to do so);"
(I sincerely hope I haven't misconstrued the situation or missed anything
Kaspar intended.)
Those of us in favor of enabling stapling by default for those using the
default configs wouldn't have any trouble finding opposite justifications.
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.
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.
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.
Looking up the values of the User and Group directives can possibly invoke
one of multiple different network services depending on the system
configuration. But I admit that's just fishing for a counter argument.
Any suggestions for breaking the apparent impasse?
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?
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.)
Thanks,
Jeff
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Posted by Brian Smith <br...@briansmith.org>.
Kaspar Brand <ht...@velox.ch> 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.
This is not true. In the case of Firefox, and I believe Chrome, it was
decided that the website is responsible for delivering the OCSP response
(via stapling) for the end-entity, and the browser is responsible for
getting the revocation info for the intermediates *in some unspecified
way*. In practice, that way is CRLSets. I think MSIE is or has also started
moving to that model.
In particular, browser makers aren't interested in RFC 6961 because of it
is a poor performance trade-off and also never implemented.
> 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.
>
This is a chicken-and-egg problem. The proposed Must-Staple feature makes
OCSP useful. Obviously Must-Staple only works if the server staples the
response. Conversely, without Must-Staple, OCSP is useless in browsers.
> 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 main motivation for OCSP stapling is to demonstrate that OCSP stapling
works in a widespread way, so that browsers can start implementing the
Must-Staple feature and gather useful metrics about the effects, including
any possible negative side effects.
> As I wrote in my reply at that time, changing the default in trunk will
> hardly help in getting broader real-world testing results.
It has to be changed on Trunk before it can be changed anywhere else, right?
> 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).
>
I agree.
And, to be perfectly honest, there are a lot of things that can go wrong
with OCSP stapling and I've yet to see an implementation without a serious
flaw.
> 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.
>
Using that argument, it isn't safe to use the server's end-entity
certificate either, because it hasn't been checked for validity. In
particular, it hasn't been checked for revocation! The Heartbleed
vulnerability had such a huge impact partially because there was no
**effective** and easy-to-use way for servers to revoke certificates. We
need to find a solution to revocation and I think that Apache enabling OCSP
stapling by default is the next step towards a solution.
> The default configuration should not trigger unsolicited outgoing
> queries to untrusted systems, for both a) and b), that's how I would
> put it.
Look at IIS, which has been doing OCSP stapling by default, without
significant problems, for many years now. Has anybody really been harmed by
IIS's default? I don't think so. I think this is an instance of the perfect
being the enemy of the good.
> Additionally, features enabled by default need to have sufficient
> coverage in the test framework.
>
Again, I agree.
In case it would be helpful: When I was at Mozilla, my team created a new
certificate verification library for Firefox. That includes a complete
implementation of OCSP verification. It also includes a small test suite
for OCSP verification. We intentionally licensed it under the Apache 2.0
license so that Apache could use the code, if Apache wants to use it. If
nothing else, the OCSP tests [3] might be a useful model for Apache's tests.
After I left Mozilla, I separated out the implementation from Firefox's
repository and made it available on GitHub: [1]. I spent some time making
that code work with OpenSSL in a branch [2].
[1] https://github.com/briansmith/mozillapkix
[2] https://github.com/briansmith/mozillapkix/tree/feature/openssl
[3]
https://github.com/briansmith/mozillapkix/blob/master/test/gtest/pkixocsp_VerifyEncodedOCSPResponse.cpp
Cheers,
Brian
--
https://briansmith.org/
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Sep 6, 2015 8:09 AM, "Kaspar Brand" <ht...@velox.ch> wrote:
>
> On 05.09.2015 13:06, Tim Bannister wrote:
> > It's not just conventional browsers. I think automated / embedded
> > HTTP clients will also benefit from stapling, either because
> > networking filters would block a conversation between the client and
> > the CA's OCSP responder, or the extra latency from using conventional
> > OCSP is a problem.
>
> That hope is mostly futile:
Kaspar,
It might help to pause here and ask what your hope or aspiration is, here.
I am reading a lot of 'no, not that' in your messages, but very little
'this instead would improve the status quo.'. Please share so we aren't
talking past one another
Yours,
Bill
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Posted by Kaspar Brand <ht...@velox.ch>.
On 05.09.2015 13:06, Tim Bannister wrote:
> It's not just conventional browsers. I think automated / embedded
> HTTP clients will also benefit from stapling, either because
> networking filters would block a conversation between the client and
> the CA's OCSP responder, or the extra latency from using conventional
> OCSP is a problem.
That hope is mostly futile: OpenSSL e.g., presumably quite popular
for implementing such clients, does not include any readily available
support for enabling OCSP checking in client mode. And even if a library
has some sort of knob for turning it on (Sun^WOracle's CertPath provider
e.g.), you'll mostly find that they don't handle stapled responses.
Consider yourself happy if a client at least does some sort of hostname
verification (see https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf for
further background, the situation didn't change fundamentally since then).
> For another example of a non-interactive application implementing
> OCSP, look at the Exim mail transfer agent (which can be both client
> and server).
SMTP with STARTTLS isn't a useful example, sorry... it's opportunistic
encryption only in the best case, and for MTA communications, DANE-EE
(https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/) looks
like a more promising approach.
Kaspar
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Posted by Tim Bannister <is...@c8h10n4o2.org.uk>.
On 5 Sep 2015, at 11:53, Ben Laurie <be...@links.org> wrote:
> On Sat, 5 Sep 2015 at 09:32 Kaspar Brand <ht...@velox.ch> wrote:
>> On 04.09.2015 17:54, Rob Stradling wrote:
>>> Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling enabled. Browsers aren't likely to start hard-failing by default until that % is a lot higher.
>
> …the reason browsers don't hard fail is because OCSP (or any out of band communication) is unreliable. So that either means you fail for sites that are actually perfectly OK, or you allow an attacker to override revocation (by blocking OCSP).
…
> Blocking stapling (and presumably you will also object to CT for similar reasons) is hurting security.
>
> 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.
It's not just conventional browsers. I think automated / embedded HTTP clients will also benefit from stapling, either because networking filters would block a conversation between the client and the CA's OCSP responder, or the extra latency from using conventional OCSP is a problem.
For another example of a non-interactive application implementing OCSP, look at the Exim mail transfer agent (which can be both client and server).
--
Tim Bannister – isoma@c8h10n4o2.org.uk
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Posted by Reindl Harald <h....@thelounge.net>.
Am 06.09.2015 um 15:06 schrieb Kaspar Brand:
> 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.
"fairly robust" don't change the fact that they would be a perfect DDOS
target and so an attacker would point one botnet to your server and the
other to the matching OCSP responder - not to forget how many sites you
can DDOS in case of clients would enforce OCSP and hard-fail
currently they are not a target for such attacks
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Posted by Kaspar Brand <ht...@velox.ch>.
On 05.09.2015 12:53, Ben Laurie wrote:
> On Sat, 5 Sep 2015 at 09:32 Kaspar Brand <ht...@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
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Posted by Ben Laurie <be...@links.org>.
On Sat, 5 Sep 2015 at 09:32 Kaspar Brand <ht...@velox.ch> wrote:
> On 04.09.2015 17:54, Rob Stradling wrote:
> > Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling
> > enabled. Browsers aren't likely to start hard-failing by default until
> > that % is a lot higher.
> >
> > The vast majority of the servers that have OCSP stapling enabled are
> > running IIS. I claim that this is due to the fact that IIS enables OCSP
> > stapling by default.
>
> The relevant metric is the percentage of (initial) TLS handshakes with
> stapled responses, not so much the percentage of servers with stapling
> enabled. Judging from Mozilla's telemetry data for Firefox 39 and 40,
> that percentage is still below 15%, and enabling stapling in an httpd
> config file which gets used by a very small number of Apache httpd admins
> (as opposed to those settings which go out to the world via [1] or [2])
> doesn't look like a very effective way of achieving the goal of making
> that percentage "a lot higher".
>
> 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. 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.
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.
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.
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. Someone has to choose the default, and IMO
the ASF should always default to "more secure".
> > I think you've misunderstood the "speed, speed, speed" argument.
> >
> > If an OCSP response is delivered via stapling, then there's no need for
> > the browser to block the TLS handshake whilst it obtains an OCSP
> > response directly from the CA's OCSP responder.
>
> No, I didn't misunderstand. That's very much the essence of the "speed,
> speed, speed" argument - "our browser must be able to complete every TLS
> handshake in under 100 ms"... even if for a specific server, it's just
> one TLS handshake per day where it really matters.
>
> > Stapling provides a noticeable speedup even if the browser never caches
> > OCSP responses.
>
> Fairly hypothetical point - I'm not aware of any common browser which
> would use a cert validation library without an OCSP cache.
>
> Kaspar
>
>
> [1] https://git.centos.org/blob/rpms!httpd.git/c7/SOURCES!ssl.conf
>
> [2]
> https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/apache2/trusty/view/head:/debian/config-dir/sites-available/default-ssl
>
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Posted by Kaspar Brand <ht...@velox.ch>.
On 04.09.2015 17:54, Rob Stradling wrote:
> Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling
> enabled. Browsers aren't likely to start hard-failing by default until
> that % is a lot higher.
>
> The vast majority of the servers that have OCSP stapling enabled are
> running IIS. I claim that this is due to the fact that IIS enables OCSP
> stapling by default.
The relevant metric is the percentage of (initial) TLS handshakes with
stapled responses, not so much the percentage of servers with stapling
enabled. Judging from Mozilla's telemetry data for Firefox 39 and 40,
that percentage is still below 15%, and enabling stapling in an httpd
config file which gets used by a very small number of Apache httpd admins
(as opposed to those settings which go out to the world via [1] or [2])
doesn't look like a very effective way of achieving the goal of making
that percentage "a lot higher".
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 think you've misunderstood the "speed, speed, speed" argument.
>
> If an OCSP response is delivered via stapling, then there's no need for
> the browser to block the TLS handshake whilst it obtains an OCSP
> response directly from the CA's OCSP responder.
No, I didn't misunderstand. That's very much the essence of the "speed,
speed, speed" argument - "our browser must be able to complete every TLS
handshake in under 100 ms"... even if for a specific server, it's just
one TLS handshake per day where it really matters.
> Stapling provides a noticeable speedup even if the browser never caches
> OCSP responses.
Fairly hypothetical point - I'm not aware of any common browser which
would use a cert validation library without an OCSP cache.
Kaspar
[1] https://git.centos.org/blob/rpms!httpd.git/c7/SOURCES!ssl.conf
[2] https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/apache2/trusty/view/head:/debian/config-dir/sites-available/default-ssl
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Posted by Rob Stradling <ro...@comodo.com>.
On 04/09/15 15:59, Kaspar Brand wrote:
> On 02.09.2015 01:54, Jeff Trawick wrote:
>> On 08/30/2015 02:30 AM, Kaspar Brand wrote:
>>> 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.
>
> It's not a blocker, sure, but on the other hand, the benefit of enabling
> stapling by default isn't that big either - as long as browsers don't
> hard-fail when OCSP information isn't available.
Kaspar,
Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling
enabled. Browsers aren't likely to start hard-failing by default until
that % is a lot higher.
The vast majority of the servers that have OCSP stapling enabled are
running IIS. I claim that this is due to the fact that IIS enables OCSP
stapling by default.
If we don't enable OCSP stapling by default in httpd, how are we going
to increase that % ?
> The "speed, speed,
> speed" argument (coming mostly from the browser vendors) isn't too
> convincing to me neither, as OCSP replies are usually cached for one
> or two days, and the typical user doesn't connect to thousands of
> new/different SSL sites per day.
I think you've misunderstood the "speed, speed, speed" argument.
If an OCSP response is delivered via stapling, then there's no need for
the browser to block the TLS handshake whilst it obtains an OCSP
response directly from the CA's OCSP responder.
Stapling provides a noticeable speedup even if the browser never caches
OCSP responses.
>> Is there a synopsis of which browsers support it for which types of
>> certificates?
>
> I don't think so, and it's probably also kind of a moving target. Chrome
> "supports" it for DV and OV as well - it will include a status_request
> extension in the TLS handshake by default -, but what I meant with
> "enforces" is that it won't care if there's no stapled response
> (Google's ceterum censeo used to be "Revocation doesn't work", which in
> 2012 lead to their implementation of CRL sets where the code is public,
> but "the process by which they are generated is not",
> https://dev.chromium.org/Home/chromium-security/crlsets).
>
> For EV certs, the browser behavior is more uniform, though strict hard
> fail enforcement still isn't happening - for testing purposes, try
> this experiment: block connections to sr.symcb.com:80 and sr.symcd.com:80,
> and point the browser to
> https://test-sspev.verisign.com:2443/test-SSPEV-revoked-verisign.html.
> With strict revocation checking enforced, no browser should ever render
> any content of the "Revoked VeriSign Secure Site Pro with EV Certificate
> Test Page" (but most do when revocation information is not available,
> although some at least show warnings or downgrade the UI to non-EV).
>
>> 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.
>
> Ok, if it's about 2.6/3.0, then we're indeed talking of a timeframe of
> several years, I assume. What I don't like with this approach in any
> case, however, is that we as the devs decide on behalf of the admins,
> instead of letting them make an informed decision. I' really arguing
> in favor of something like this in httpd-ssl.conf.in:
>
> --- snip ---
> # SSL Engine Switch:
> # Enable/Disable SSL for this virtual host.
> SSLEngine on
>
> # Server Certificate and Private Key:
> # ...
> SSLCertificateFile "conf/server.crt"
> SSLCertificateKeyFile "conf/server.key"
>
> # OCSP Stapling:
> # For SSL certificates which include an OCSP responder URI, mod_ssl
> # can include revocation status information for the server's own
> # certificate in the TLS handshake. Enabling this option requires
> # outgoing connectivity to the CA's OCSP responder (usually running
> # running on port 80, use "openssl x509 -in server.crt -text" to
> # determine the exact URI), so this option is not enabled by default.
> # The responder will be queried with the interval configured
> # via SSLStaplingStandardCacheTimeout. For EV SSL certificates
> # in particular, enabling this option is recommended/useful.
> #SSLUseStapling On
> --- snip ---
>
> (i.e., move the SSLUseStapling directive closer to the cert settings,
> and make people aware of the outgoing connections this will trigger)
>
>> 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?
>
> Will do, yes. When trunk becomes 2.6/3.0 one day (and a GA release), the
> basic question remains, though: is it acceptable that configuring an SSL
> certificate potentially triggers outgoing OCSP requests in mod_ssl,
> without having been explicitly instructed to do so by an admin? My view
> is still the same as in November 2014: admins should opt in for this
> feature, not be forced to opt out.
>
>>> 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?
>
> The point I was trying to make is that stapling is a per-certificate
> feature (not a global one like SSLRandomSeed, SSLSessionCache etc.), so
> it would be best if the admin becomes aware of it when configuring the cert.
>
>>>> 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).
>
> Ok, but I wouldn't consider DNS as being implicitly configured - after
> all, the resolvers are specified when network access on the OS level is
> configured (and DNS queries are sent to nameservers which are hopefully
> authoritative for lookups of hosts in the local net).
>
>>>> 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?
>
> I was primarily trying to come up with a generic principle "which could
> be followed consistently across disparate features", so I'm not sure if
> considering specific attacks for the stapling case is the right way to
> continue the discussion... as another example, take the "Version check
> idea" thread from April 2015 [1] - even though there might not be an
> immediate threat if it were enabled by default, I really hope that httpd
> doesn't move into the direction of automatically enabling features
> requiring outgoing connectivity (without the admin's explicit
> instruction and consent).
>
>> 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.
>
> For GA releases, my position is that both criteria apply, yes. If it's
> enabled in trunk, an alpha or a beta for getting broader testing exposure,
> then the docs and release notes/announcement should prominently say so
> (not only for OCSP stapling specifically, but in general for those
> features which may trigger unsolicited outgoing connections).
>
> Kaspar
>
>
> [1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201504.mbox/%3C7C89CDBA-B463-415F-82DA-DDD6AD88C38E@jaguNET.com%3E
>
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Posted by Kaspar Brand <ht...@velox.ch>.
On 05.09.2015 14:23, Jeff Trawick wrote:
> On 09/04/2015 10:59 AM, Kaspar Brand wrote:
>>> 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.
>
> Re: "unsolicited":
>
> Key words/phrases from the other end of the continuum: "unexpected by
> many", "responder obtained from explicitly configured certificate"
The other end of the continuum would be "explicitly requested", in my
view. "unsolicited" = "not explicitly requested", that's what I intended
to say (and "explicitly" referring to something like "manually enabling
a directive").
> The unexpected aspect could be helped by a [notice] message at startup
> indicating that an OCSP responder will be contacted for N certificates
> due to the directive. (If there is only one, an alternate message could
> be displayed with the actual responder URL; we couldn't do that for
> arbitrary numbers.)
IMO, not a sufficient method for justifying a "default on" setting
(configuring a Base64 encoded certificate blob through
SSLCertificateFile doesn't amount to explicitly configuring a responder
URI).
> Re: "untrusted":
>
> The certificate and its content are untrusted in general?
Technically speaking, as long as mod_ssl doesn't validate the cert file
against a set of (locally configured) trust anchors, the complete file
is to be considered untrusted. An admin could have received a "fake
reply" for his CSR, where the public key perfectly matches the private
key, but the contents are bogus otherwise. Sure, he would most likely
realize this quite soon after having configured the cert and trying to
connect to his own server, but essentially, I wouldn't consider the
contents pointed to by an SSLCertificateFile directive as trusted.
> The content
> is trusted but the responder URL is not what/who it seems? (I wasn't
> sure where you were leading when you alluded to this in prior
> correspondence.)
X.509v3 certs can have all sorts of "useful" extensions, and I wouldn't
consider all this information automatically trusted just because it's
signed by the CA (take the OU field in the subject DN as an example:
most CAs will have disclaimers stating that these fields are basically
"unverified").
With the OCSP URI in particular, an additional aspect of "untrusted" is
that resolving its IP address(es) relies on the DNS, i.e. a component
which can't be considered trusted when it is queried for records of
third-party domains.
Kaspar
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Posted by Jeff Trawick <tr...@gmail.com>.
On 09/04/2015 10:59 AM, Kaspar Brand wrote:
> On 02.09.2015 01:54, Jeff Trawick wrote:
>> On 08/30/2015 02:30 AM, Kaspar Brand wrote:
>>> 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.
> It's not a blocker, sure, but on the other hand, the benefit of enabling
> stapling by default isn't that big either - as long as browsers don't
> hard-fail when OCSP information isn't available. The "speed, speed,
> speed" argument (coming mostly from the browser vendors) isn't too
> convincing to me neither, as OCSP replies are usually cached for one
> or two days, and the typical user doesn't connect to thousands of
> new/different SSL sites per day.
>
>> Is there a synopsis of which browsers support it for which types of
>> certificates?
> I don't think so, and it's probably also kind of a moving target. Chrome
> "supports" it for DV and OV as well - it will include a status_request
> extension in the TLS handshake by default -, but what I meant with
> "enforces" is that it won't care if there's no stapled response
> (Google's ceterum censeo used to be "Revocation doesn't work", which in
> 2012 lead to their implementation of CRL sets where the code is public,
> but "the process by which they are generated is not",
> https://dev.chromium.org/Home/chromium-security/crlsets).
>
> For EV certs, the browser behavior is more uniform, though strict hard
> fail enforcement still isn't happening - for testing purposes, try
> this experiment: block connections to sr.symcb.com:80 and sr.symcd.com:80,
> and point the browser to
> https://test-sspev.verisign.com:2443/test-SSPEV-revoked-verisign.html.
> With strict revocation checking enforced, no browser should ever render
> any content of the "Revoked VeriSign Secure Site Pro with EV Certificate
> Test Page" (but most do when revocation information is not available,
> although some at least show warnings or downgrade the UI to non-EV).
>
>> 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.
> Ok, if it's about 2.6/3.0, then we're indeed talking of a timeframe of
> several years, I assume. What I don't like with this approach in any
> case, however, is that we as the devs decide on behalf of the admins,
> instead of letting them make an informed decision. I' really arguing
> in favor of something like this in httpd-ssl.conf.in:
>
> --- snip ---
> # SSL Engine Switch:
> # Enable/Disable SSL for this virtual host.
> SSLEngine on
>
> # Server Certificate and Private Key:
> # ...
> SSLCertificateFile "conf/server.crt"
> SSLCertificateKeyFile "conf/server.key"
>
> # OCSP Stapling:
> # For SSL certificates which include an OCSP responder URI, mod_ssl
> # can include revocation status information for the server's own
> # certificate in the TLS handshake. Enabling this option requires
> # outgoing connectivity to the CA's OCSP responder (usually running
> # running on port 80, use "openssl x509 -in server.crt -text" to
> # determine the exact URI), so this option is not enabled by default.
> # The responder will be queried with the interval configured
> # via SSLStaplingStandardCacheTimeout. For EV SSL certificates
> # in particular, enabling this option is recommended/useful.
> #SSLUseStapling On
> --- snip ---
>
> (i.e., move the SSLUseStapling directive closer to the cert settings,
> and make people aware of the outgoing connections this will trigger)
>
>> 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?
> Will do, yes. When trunk becomes 2.6/3.0 one day (and a GA release), the
> basic question remains, though: is it acceptable that configuring an SSL
> certificate potentially triggers outgoing OCSP requests in mod_ssl,
> without having been explicitly instructed to do so by an admin? My view
> is still the same as in November 2014: admins should opt in for this
> feature, not be forced to opt out.
>
>>> 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?
> The point I was trying to make is that stapling is a per-certificate
> feature (not a global one like SSLRandomSeed, SSLSessionCache etc.), so
> it would be best if the admin becomes aware of it when configuring the cert.
>
>>>> 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).
> Ok, but I wouldn't consider DNS as being implicitly configured - after
> all, the resolvers are specified when network access on the OS level is
> configured (and DNS queries are sent to nameservers which are hopefully
> authoritative for lookups of hosts in the local net).
>
>>>> 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?
> I was primarily trying to come up with a generic principle "which could
> be followed consistently across disparate features", so I'm not sure if
> considering specific attacks for the stapling case is the right way to
> continue the discussion... as another example, take the "Version check
> idea" thread from April 2015 [1] - even though there might not be an
> immediate threat if it were enabled by default, I really hope that httpd
> doesn't move into the direction of automatically enabling features
> requiring outgoing connectivity (without the admin's explicit
> instruction and consent).
>
>> 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.
Re: "unsolicited":
Key words/phrases from the other end of the continuum: "unexpected by
many", "responder obtained from explicitly configured certificate"
The unexpected aspect could be helped by a [notice] message at startup
indicating that an OCSP responder will be contacted for N certificates
due to the directive. (If there is only one, an alternate message could
be displayed with the actual responder URL; we couldn't do that for
arbitrary numbers.)
Re: "untrusted":
The certificate and its content are untrusted in general? The content
is trusted but the responder URL is not what/who it seems? (I wasn't
sure where you were leading when you alluded to this in prior
correspondence.)
>> 2. Additionally, features enabled by default need to have sufficient
>> coverage in the test framework.
> For GA releases, my position is that both criteria apply, yes. If it's
> enabled in trunk, an alpha or a beta for getting broader testing exposure,
> then the docs and release notes/announcement should prominently say so
> (not only for OCSP stapling specifically, but in general for those
> features which may trigger unsolicited outgoing connections).
>
> Kaspar
>
>
> [1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201504.mbox/%3C7C89CDBA-B463-415F-82DA-DDD6AD88C38E@jaguNET.com%3E
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Posted by Kaspar Brand <ht...@velox.ch>.
On 02.09.2015 01:54, Jeff Trawick wrote:
> On 08/30/2015 02:30 AM, Kaspar Brand wrote:
>> 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.
It's not a blocker, sure, but on the other hand, the benefit of enabling
stapling by default isn't that big either - as long as browsers don't
hard-fail when OCSP information isn't available. The "speed, speed,
speed" argument (coming mostly from the browser vendors) isn't too
convincing to me neither, as OCSP replies are usually cached for one
or two days, and the typical user doesn't connect to thousands of
new/different SSL sites per day.
> Is there a synopsis of which browsers support it for which types of
> certificates?
I don't think so, and it's probably also kind of a moving target. Chrome
"supports" it for DV and OV as well - it will include a status_request
extension in the TLS handshake by default -, but what I meant with
"enforces" is that it won't care if there's no stapled response
(Google's ceterum censeo used to be "Revocation doesn't work", which in
2012 lead to their implementation of CRL sets where the code is public,
but "the process by which they are generated is not",
https://dev.chromium.org/Home/chromium-security/crlsets).
For EV certs, the browser behavior is more uniform, though strict hard
fail enforcement still isn't happening - for testing purposes, try
this experiment: block connections to sr.symcb.com:80 and sr.symcd.com:80,
and point the browser to
https://test-sspev.verisign.com:2443/test-SSPEV-revoked-verisign.html.
With strict revocation checking enforced, no browser should ever render
any content of the "Revoked VeriSign Secure Site Pro with EV Certificate
Test Page" (but most do when revocation information is not available,
although some at least show warnings or downgrade the UI to non-EV).
> 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.
Ok, if it's about 2.6/3.0, then we're indeed talking of a timeframe of
several years, I assume. What I don't like with this approach in any
case, however, is that we as the devs decide on behalf of the admins,
instead of letting them make an informed decision. I' really arguing
in favor of something like this in httpd-ssl.conf.in:
--- snip ---
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# Server Certificate and Private Key:
# ...
SSLCertificateFile "conf/server.crt"
SSLCertificateKeyFile "conf/server.key"
# OCSP Stapling:
# For SSL certificates which include an OCSP responder URI, mod_ssl
# can include revocation status information for the server's own
# certificate in the TLS handshake. Enabling this option requires
# outgoing connectivity to the CA's OCSP responder (usually running
# running on port 80, use "openssl x509 -in server.crt -text" to
# determine the exact URI), so this option is not enabled by default.
# The responder will be queried with the interval configured
# via SSLStaplingStandardCacheTimeout. For EV SSL certificates
# in particular, enabling this option is recommended/useful.
#SSLUseStapling On
--- snip ---
(i.e., move the SSLUseStapling directive closer to the cert settings,
and make people aware of the outgoing connections this will trigger)
> 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?
Will do, yes. When trunk becomes 2.6/3.0 one day (and a GA release), the
basic question remains, though: is it acceptable that configuring an SSL
certificate potentially triggers outgoing OCSP requests in mod_ssl,
without having been explicitly instructed to do so by an admin? My view
is still the same as in November 2014: admins should opt in for this
feature, not be forced to opt out.
>> 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?
The point I was trying to make is that stapling is a per-certificate
feature (not a global one like SSLRandomSeed, SSLSessionCache etc.), so
it would be best if the admin becomes aware of it when configuring the cert.
>>> 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).
Ok, but I wouldn't consider DNS as being implicitly configured - after
all, the resolvers are specified when network access on the OS level is
configured (and DNS queries are sent to nameservers which are hopefully
authoritative for lookups of hosts in the local net).
>>> 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?
I was primarily trying to come up with a generic principle "which could
be followed consistently across disparate features", so I'm not sure if
considering specific attacks for the stapling case is the right way to
continue the discussion... as another example, take the "Version check
idea" thread from April 2015 [1] - even though there might not be an
immediate threat if it were enabled by default, I really hope that httpd
doesn't move into the direction of automatically enabling features
requiring outgoing connectivity (without the admin's explicit
instruction and consent).
> 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.
For GA releases, my position is that both criteria apply, yes. If it's
enabled in trunk, an alpha or a beta for getting broader testing exposure,
then the docs and release notes/announcement should prominently say so
(not only for OCSP stapling specifically, but in general for those
features which may trigger unsolicited outgoing connections).
Kaspar
[1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201504.mbox/%3C7C89CDBA-B463-415F-82DA-DDD6AD88C38E@jaguNET.com%3E
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Posted by Jeff Trawick <tr...@gmail.com>.
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
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Posted by Kaspar Brand <ht...@velox.ch>.
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. 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.
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? As
I wrote in my reply at that time, changing the default in trunk will
hardly help in getting broader real-world testing results. 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).
> 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. 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.
> 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.
> 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. 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
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Posted by Jeff Trawick <tr...@gmail.com>.
On 08/29/2015 08:10 PM, William A Rowe Jr wrote:
>
> On Aug 29, 2015 1:49 PM, "Jeff Trawick" <trawick@gmail.com
> <ma...@gmail.com>> wrote:
> >
> > On 08/28/2015 04:17 PM, Tim Bannister wrote:
> >>
> >> Jeff Trawick <trawick@gmail.com <ma...@gmail.com>> wrote:
> >>>
> >>>
> >>> As of now there's still a veto on my suggestion of enabling
> stapling by
> >>> default in the httpd trunk config.
> >>
> >> Would that default need to be backported to 2.4.x?
> >
> >
> > "need"? No; 2.4.x is a separate consideration.
> >
> >
> >> If it can be on by default for trunk/2.5.x, and off by default in
> earlier releases, this should surprise very few users.
> >>
> >> People upgrading from an older release could get a mild surprise,
> but at the same time if you upgrade from 2.4.x to 2.5.x then surprises
> aren't all that surprising.
> >>
> >> Overall I think the big question mark is around backport to 2.4.x
> rather than the change to httpd trunk.
>
> I thought this question was largely resolved, that we wouldn't want
> subversion updates to break a users config unexpectedly. POLS.
>
You know this, but just for completeness:
Subversion-update-breaks-users-config is when compiled-in default
behavior changes, which could affect configurations with no stapling
directive, which wasn't proposed even for trunk.
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Aug 29, 2015 1:49 PM, "Jeff Trawick" <tr...@gmail.com> wrote:
>
> On 08/28/2015 04:17 PM, Tim Bannister wrote:
>>
>> Jeff Trawick <tr...@gmail.com> wrote:
>>>
>>>
>>> As of now there's still a veto on my suggestion of enabling stapling by
>>> default in the httpd trunk config.
>>
>> Would that default need to be backported to 2.4.x?
>
>
> "need"? No; 2.4.x is a separate consideration.
>
>
>> If it can be on by default for trunk/2.5.x, and off by default in
earlier releases, this should surprise very few users.
>>
>> People upgrading from an older release could get a mild surprise, but at
the same time if you upgrade from 2.4.x to 2.5.x then surprises aren't all
that surprising.
>>
>> Overall I think the big question mark is around backport to 2.4.x rather
than the change to httpd trunk.
I thought this question was largely resolved, that we wouldn't want
subversion updates to break a users config unexpectedly. POLS.
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Posted by Jeff Trawick <tr...@gmail.com>.
On 08/28/2015 04:17 PM, Tim Bannister wrote:
> Jeff Trawick <tr...@gmail.com> wrote:
>>
>> As of now there's still a veto on my suggestion of enabling stapling by
>> default in the httpd trunk config.
> Would that default need to be backported to 2.4.x?
"need"? No; 2.4.x is a separate consideration.
> If it can be on by default for trunk/2.5.x, and off by default in earlier releases, this should surprise very few users.
>
> People upgrading from an older release could get a mild surprise, but at the same time if you upgrade from 2.4.x to 2.5.x then surprises aren't all that surprising.
>
> Overall I think the big question mark is around backport to 2.4.x rather than the change to httpd trunk.
>
> Tim
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Posted by Tim Bannister <is...@c8h10n4o2.org.uk>.
Jeff Trawick <tr...@gmail.com> wrote:
>
>
>As of now there's still a veto on my suggestion of enabling stapling by
>default in the httpd trunk config.
Would that default need to be backported to 2.4.x?
If it can be on by default for trunk/2.5.x, and off by default in earlier releases, this should surprise very few users.
People upgrading from an older release could get a mild surprise, but at the same time if you upgrade from 2.4.x to 2.5.x then surprises aren't all that surprising.
Overall I think the big question mark is around backport to 2.4.x rather than the change to httpd trunk.
Tim
--
Tim Bannister – isoma@c8h10n4o2.org.uk