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.
