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-ddd6ad88c...@jagunet.com%3E
