Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On Sep 6, 2015 8:09 AM, "Kaspar Brand"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
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
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 signature.asc Description: OpenPGP digital signature
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On 05.09.2015 12:53, Ben Laurie wrote: > On Sat, 5 Sep 2015 at 09:32 Kaspar Brandwrote: >> 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
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
On Sat, 5 Sep 2015 at 09:32 Kaspar Brandwrote: > 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
On 5 Sep 2015, at 11:53, Ben Lauriewrote: > On Sat, 5 Sep 2015 at 09:32 Kaspar Brand 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 – is...@c8h10n4o2.org.uk
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
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
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")
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
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
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
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
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
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
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On 08/29/2015 08:10 PM, William A Rowe Jr wrote: On Aug 29, 2015 1:49 PM, "Jeff Trawick"> wrote: > > On 08/28/2015 04:17 PM, Tim Bannister wrote: >> >> Jeff Trawick > 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
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
Kaspar Brand httpd-dev.2...@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: AW: [RFC] Enable OCSP Stapling by default in httpd trunk
On 29.08.2015 17:56, olli hauer wrote: On 2015-07-03 12:13, Plüm, Rüdiger, Vodafone Group wrote: Thanks for the detailed explanation. So yes OCSP stapling is really beneficial if it is possible for the server admin to set it up. But it likely requires additional configuration steps outside of httpd to make the OCSP responder reachable (like firewall clearances) and leads to otherwise strange slow responses if this is not prepared. Another obstacle with the current stapling code is that the connection to the OCSP responder of the CA needs to happen directly and cannot be done via a proxy. Hence I agree with Kaspar that it should be off by default. Not tested, but looking at the mod_ssl doc it seems SSLStaplingForceURL can be used to proxy requests to the OCSP responder(s) http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslstaplingforceurl In case SSLStaplingForceURL can be used to force OCSP requests via proxy it would be nice to add something like the following patch before enabling OCSP stapling as default. It can't be used like this, as pointed out in [1]. Its main use is for certs which do not include an OCSP URI at all, so configuring SSLStaplingForceURL at the global level doesn't make much sense - you would have to run a transparent OCSP proxy at that URL (mod_ssl will just send plain OCSP requests to this address). Kaspar [1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201411.mbox/%3C5454A1FE.6060204%40velox.ch%3E
Re: AW: [RFC] Enable OCSP Stapling by default in httpd trunk
On 2015-07-03 12:13, Plüm, Rüdiger, Vodafone Group wrote: -Ursprüngliche Nachricht- Von: Rob Stradling [mailto:rob.stradl...@comodo.com] Gesendet: Freitag, 3. Juli 2015 12:01 An: dev@httpd.apache.org Betreff: Re: [RFC] Enable OCSP Stapling by default in httpd trunk On 02/07/15 19:03, Ruediger Pluem wrote: snip Just to be sure I don't miss anything. This is not about disabling OCSP, its about disabling OCSP stapling by default. Maybe I have a wrong understanding of OCSP stapling, but to me stapling only provides performance improvements, not security improvements for the client as the client still could connect to the OCSP URL given in the cert directly and get the answer from there. If the response is stabled it does not need to (with the same level of security) and saves itself a roundtrip to the OCSP server of the CA and the OCSP server of the CA a request to process. Yes, the client _could_ connect to the OCSP URL given in the cert directly and get the answer from there. However, at least one major browser (Chrome) no longer does this, but it does process stapled OCSP responses. Even if we could ignore Chrome... There will always be some clients that cannot reach the CA's OCSP responder directly (due to connectivity issues at the client side), whereas the TLS servers that those clients connect to may well have better connectivity (and thus be able to staple OCSP responses that the client cannot obtain by any other means). Also, this isn't just about performance. If a client contacts an OCSP responder directly, it reveals to the CA that it is interested in a particular certificate. That's a far worse privacy leak than a TLS server contacting a CA's OCSP responder and revealing that it's interested in the status of its own certificate!! Thanks for the detailed explanation. So yes OCSP stapling is really beneficial if it is possible for the server admin to set it up. But it likely requires additional configuration steps outside of httpd to make the OCSP responder reachable (like firewall clearances) and leads to otherwise strange slow responses if this is not prepared. Another obstacle with the current stapling code is that the connection to the OCSP responder of the CA needs to happen directly and cannot be done via a proxy. Hence I agree with Kaspar that it should be off by default. Not tested, but looking at the mod_ssl doc it seems SSLStaplingForceURL can be used to proxy requests to the OCSP responder(s) http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslstaplingforceurl In case SSLStaplingForceURL can be used to force OCSP requests via proxy it would be nice to add something like the following patch before enabling OCSP stapling as default. Index: trunk/docs/conf/extra/httpd-ssl.conf.in === --- trunk/docs/conf/extra/httpd-ssl.conf.in (revision 1700039) +++ trunk/docs/conf/extra/httpd-ssl.conf.in (working copy) @@ -114,6 +114,11 @@ # Seconds before invalid OCSP responses are expired from the cache #SSLStaplingErrorCacheTimeout 600 +# This directive overrides the URI of an OCSP responder as obtained +# from the authorityInfoAccess (AIA) extension of the certificate. +# One potential use is when a proxy is used for retrieving OCSP queries. +#SSLStaplingForceURL http://internal.proxy.local + ## ## SSL Virtual Host Context ##
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On Aug 29, 2015 1:49 PM, Jeff Trawick traw...@gmail.com wrote: On 08/28/2015 04:17 PM, Tim Bannister wrote: Jeff Trawick traw...@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
On Mon, Jul 13, 2015 at 3:08 AM, Ruediger Pluem rpl...@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
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
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On 01.07.2015 14:27, Ben Laurie wrote: On 1 November 2014 at 09:05, Kaspar Brand httpd-dev.2...@velox.ch wrote: The fundamental objection I have to enabling stapling by default in our GA releases is that it would enable a phoning home feature (to the CA's OCSP responders) as a side effect of configuring a certificate. This is a setting I consider unacceptable for software published by the Apache HTTP Server project - the default must be opt-in, not opt-out. I've just become aware of this objection and would like to understand the thinking behind it. Firstly, it seems strange to call this phoning home, a term that _usually_ means connecting to the vendor of the s/w. But more importantly, what harm is there in a server connecting to the OCSP responders for the certificates it is serving? Why is this unacceptable? It's unacceptable for at least two reasons: 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); b) there's no statement in our license with an explicit caveat on such a side effect (when relying on our default settings, configuring a site with an SSL server certificate may result in unsolicited outgoing HTTP requests - and no, I do not want to see our license amended by things like that). I maintain my objection to uncommenting #SSLUseStapling On in our default config in httpd-ssl.conf.in - and for the record, also to changing code, be that in ssl_engine_config.c:modssl_ctx_init() or elsewhere. Those keen on enabling it by default on behalf of the users (because we know what is good for you) are free to lobby with the OS vendors to have their package defaults changed. Kaspar
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
We can have a dialog about the best behavior of our default config. However... On Sat, Jul 11, 2015 at 9:56 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote: On 01.07.2015 14:27, Ben Laurie wrote: On 1 November 2014 at 09:05, Kaspar Brand httpd-dev.2...@velox.ch wrote: The fundamental objection I have to enabling stapling by default in our GA releases is that it would enable a phoning home feature (to the CA's OCSP responders) as a side effect of configuring a certificate. This is a setting I consider unacceptable for software published by the Apache HTTP Server project - the default must be opt-in, not opt-out. I've just become aware of this objection and would like to understand the thinking behind it. Firstly, it seems strange to call this phoning home, a term that _usually_ means connecting to the vendor of the s/w. But more importantly, what harm is there in a server connecting to the OCSP responders for the certificates it is serving? Why is this unacceptable? It's unacceptable for at least two reasons: 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); b) there's no statement in our license with an explicit caveat on such a side effect (when relying on our default settings, configuring a site with an SSL server certificate may result in unsolicited outgoing HTTP requests - and no, I do not want to see our license amended by things like that). Our License says nothing about accepting requests, either. Licenses don't express these mechanics. They define the terms for users to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the work and its derivatives, and the corresponding patent rights as well. A number of ASF works are servers. A number are clients. A number are both clients and servers. OCSP is hardly an accidental request, any more than the proxy module requests. And in forwarding requests to https proxy servers, (another side effect) verifying the OCSP identity of the connected server is hardly an unexpected side effect, it's a characteristic of the protocol (that backend *server* advertised OCSP validation - stapled or indirect, and that the *user* configured the certificate for OCSP validation). Third party OCSP validation is so problematic that OCSP stapling is a blindly obvious enhancement that will far offset the routing configuration issues it also inspires So your premise above is, well, outright silly. I maintain my objection to uncommenting #SSLUseStapling On in our default config in httpd-ssl.conf.in - and for the record, also to changing code, be that in ssl_engine_config.c:modssl_ctx_init() or elsewhere. Those keen on enabling it by default on behalf of the users (because we know what is good for you) are free to lobby with the OS vendors to have their package defaults changed. You are welcome to object, and I think Ben's reply here to your thoughts and observations, particularly your early one, since he is advocating for this change and this would move the dialog along to a conclusion. Contrawise, httpd project can do the 'right thing' from our perspective, and the downstream distributors can correspondingly disable it. Moreso, any enterprise so affected already is configuring httpd to their own organization's standards and policies. 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.
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On Sat, Jul 11, 2015 at 2:55 PM, William A Rowe Jr wr...@rowe-clan.net wrote: We can have a dialog about the best behavior of our default config. However... On Sat, Jul 11, 2015 at 9:56 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote: On 01.07.2015 14:27, Ben Laurie wrote: On 1 November 2014 at 09:05, Kaspar Brand httpd-dev.2...@velox.ch wrote: The fundamental objection I have to enabling stapling by default in our GA releases is that it would enable a phoning home feature (to the CA's OCSP responders) as a side effect of configuring a certificate. This is a setting I consider unacceptable for software published by the Apache HTTP Server project - the default must be opt-in, not opt-out. I've just become aware of this objection and would like to understand the thinking behind it. Firstly, it seems strange to call this phoning home, a term that _usually_ means connecting to the vendor of the s/w. But more importantly, what harm is there in a server connecting to the OCSP responders for the certificates it is serving? Why is this unacceptable? It's unacceptable for at least two reasons: 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); b) there's no statement in our license with an explicit caveat on such a side effect (when relying on our default settings, configuring a site with an SSL server certificate may result in unsolicited outgoing HTTP requests - and no, I do not want to see our license amended by things like that). Our License says nothing about accepting requests, either. Licenses don't express these mechanics. They define the terms for users to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the work and its derivatives, and the corresponding patent rights as well. A number of ASF works are servers. A number are clients. A number are both clients and servers. OCSP is hardly an accidental request, any more than the proxy module requests. And in forwarding requests to https proxy servers, (another side effect) verifying the OCSP identity of the connected server is hardly an unexpected side effect, it's a characteristic of the protocol (that backend *server* advertised OCSP validation - stapled or indirect, and that the *user* configured the certificate for OCSP validation). Third party OCSP validation is so problematic that OCSP stapling is a blindly obvious enhancement that will far offset the routing configuration issues it also inspires So your premise above is, well, outright silly. I maintain my objection to uncommenting #SSLUseStapling On in our default config in httpd-ssl.conf.in - and for the record, also to changing code, be that in ssl_engine_config.c:modssl_ctx_init() or elsewhere. Those keen on enabling it by default on behalf of the users (because we know what is good for you) are free to lobby with the OS vendors to have their package defaults changed. You are welcome to object, and I think Ben's reply here to your thoughts and observations, particularly your early one, since he is advocating for this change and this would move the dialog along to a conclusion. Contrawise, httpd project can do the 'right thing' from our perspective, and the downstream distributors can correspondingly disable it. Moreso, any enterprise so affected already is configuring httpd to their own organization's standards and policies. 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. Not to anyone in particular: Contacting the OCSP responder may indeed be a surprise, and it might not even work due to to firewall rules being effectively surprised. (DNS was too once upon a time.) It does require education on the part of some administrators. But: No changes discussed actually change the behavior for any non-hypothetical configuration, since SSL is not configured by default and no existing configurations will magically start contacting the responder. (The more nuanced wording of OCSP stapling by default is IFF you're using the latest httpd default configuration files, an OCSP responder pointed to in a certificate you configure will be utilized, unless you say otherwise.). The config change does move the key decision point regarding this new concept to the basic enablement of SSL. In retrospect, it might have been wise to enable/disable stapling on the SSLCertificateFile directive, both for the more granular control as well as making the admin see the setting when performing that required bit of configuration. -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: AW: [RFC] Enable OCSP Stapling by default in httpd trunk
On Jul 3, 2015 9:37 AM, Rob Stradling rob.stradl...@comodo.com wrote: On 03/07/15 11:13, Plüm, Rüdiger, Vodafone Group wrote: snip Thanks for the detailed explanation. So yes OCSP stapling is really beneficial if it is possible for the server admin to set it up. But it likely requires additional configuration steps outside of httpd to make the OCSP responder reachable (like firewall clearances) and leads to otherwise strange slow responses if this is not prepared. Another obstacle with the current stapling code is that the connection to the OCSP responder of the CA needs to happen directly and cannot be done via a proxy. Hence I agree with Kaspar that it should be off by default. Given the current stapling code, that's fair enough. Is it feasible to engineer around these issues so that stapling could be enabled by default in some future httpd release? If not, what's the showstopper? This was Ben's suggestion, top post. At this project, the trunk of svn is the next major or minor version, e g 3.0 or 2.6 eventually, that would be after a 2.5 beta cycle to hash out the kinks. I'm strongly in favor of enabling this by default as a down-the-road opportunity, and current concerns can be better addressed if everyone who is touching that future 2.5.0+ version is looking at all issues that arise. httpd 2.6/3.0 may well disable plaintext out-of-the-box, with a default tls listener, sni named vhosts and http/2 enabled by default. Ignoring stapling due to enterprises that have no other reason to start supporting ocsp and other modern validation and verification tools should not be a primary goal, from the forward looking convention. If it can't be solved with code, then it can always be changed back to default of disabled before GA.
Re: AW: [RFC] Enable OCSP Stapling by default in httpd trunk
On 03/07/15 11:13, Plüm, Rüdiger, Vodafone Group wrote: snip Thanks for the detailed explanation. So yes OCSP stapling is really beneficial if it is possible for the server admin to set it up. But it likely requires additional configuration steps outside of httpd to make the OCSP responder reachable (like firewall clearances) and leads to otherwise strange slow responses if this is not prepared. Another obstacle with the current stapling code is that the connection to the OCSP responder of the CA needs to happen directly and cannot be done via a proxy. Hence I agree with Kaspar that it should be off by default. Given the current stapling code, that's fair enough. Is it feasible to engineer around these issues so that stapling could be enabled by default in some future httpd release? If not, what's the showstopper? Thanks. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On 02/07/15 19:03, Ruediger Pluem wrote: snip Just to be sure I don't miss anything. This is not about disabling OCSP, its about disabling OCSP stapling by default. Maybe I have a wrong understanding of OCSP stapling, but to me stapling only provides performance improvements, not security improvements for the client as the client still could connect to the OCSP URL given in the cert directly and get the answer from there. If the response is stabled it does not need to (with the same level of security) and saves itself a roundtrip to the OCSP server of the CA and the OCSP server of the CA a request to process. Yes, the client _could_ connect to the OCSP URL given in the cert directly and get the answer from there. However, at least one major browser (Chrome) no longer does this, but it does process stapled OCSP responses. Even if we could ignore Chrome... There will always be some clients that cannot reach the CA's OCSP responder directly (due to connectivity issues at the client side), whereas the TLS servers that those clients connect to may well have better connectivity (and thus be able to staple OCSP responses that the client cannot obtain by any other means). Also, this isn't just about performance. If a client contacts an OCSP responder directly, it reveals to the CA that it is interested in a particular certificate. That's a far worse privacy leak than a TLS server contacting a CA's OCSP responder and revealing that it's interested in the status of its own certificate!! These are the same organization whose management are often those targeted by malware anyways. It's on them if they choose to ignore what few security measures are available to the less savvy end user. Again I don't get what this has to do with malware attacks on these organizations, but maybe my understanding of OCSP stapling is entirely wrong. Regards Rüdiger -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
AW: [RFC] Enable OCSP Stapling by default in httpd trunk
-Ursprüngliche Nachricht- Von: Rob Stradling [mailto:rob.stradl...@comodo.com] Gesendet: Freitag, 3. Juli 2015 12:01 An: dev@httpd.apache.org Betreff: Re: [RFC] Enable OCSP Stapling by default in httpd trunk On 02/07/15 19:03, Ruediger Pluem wrote: snip Just to be sure I don't miss anything. This is not about disabling OCSP, its about disabling OCSP stapling by default. Maybe I have a wrong understanding of OCSP stapling, but to me stapling only provides performance improvements, not security improvements for the client as the client still could connect to the OCSP URL given in the cert directly and get the answer from there. If the response is stabled it does not need to (with the same level of security) and saves itself a roundtrip to the OCSP server of the CA and the OCSP server of the CA a request to process. Yes, the client _could_ connect to the OCSP URL given in the cert directly and get the answer from there. However, at least one major browser (Chrome) no longer does this, but it does process stapled OCSP responses. Even if we could ignore Chrome... There will always be some clients that cannot reach the CA's OCSP responder directly (due to connectivity issues at the client side), whereas the TLS servers that those clients connect to may well have better connectivity (and thus be able to staple OCSP responses that the client cannot obtain by any other means). Also, this isn't just about performance. If a client contacts an OCSP responder directly, it reveals to the CA that it is interested in a particular certificate. That's a far worse privacy leak than a TLS server contacting a CA's OCSP responder and revealing that it's interested in the status of its own certificate!! Thanks for the detailed explanation. So yes OCSP stapling is really beneficial if it is possible for the server admin to set it up. But it likely requires additional configuration steps outside of httpd to make the OCSP responder reachable (like firewall clearances) and leads to otherwise strange slow responses if this is not prepared. Another obstacle with the current stapling code is that the connection to the OCSP responder of the CA needs to happen directly and cannot be done via a proxy. Hence I agree with Kaspar that it should be off by default. Regards Rüdiger
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On 07/02/2015 07:10 PM, William A Rowe Jr wrote: On Wed, Jul 1, 2015 at 8:54 AM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com mailto:ruediger.pl...@vodafone.com wrote: -Ursprüngliche Nachricht- Von: benlau...@gmail.com mailto:benlau...@gmail.com [mailto:benlau...@gmail.com mailto:benlau...@gmail.com] Im Auftrag von Ben Laurie Gesendet: Mittwoch, 1. Juli 2015 14:27 An: dev@httpd.apache.org mailto:dev@httpd.apache.org Betreff: Re: [RFC] Enable OCSP Stapling by default in httpd trunk On 1 November 2014 at 09:05, Kaspar Brand httpd-dev.2...@velox.ch mailto:httpd-dev.2...@velox.ch wrote: On 30.10.2014 15:51, Jeff Trawick wrote: IMO the present concerns with OCSP Stapling are: * not so clear that it has seen enough real-world testing; commented out sample configs and better documentation will help, as will enabling by default in trunk (just a little?) * related bugs 57121 and 57131 A simple way to help with the broader issue raised in 57131, as well as fix 57121, is to not hold the global mutex while communicating with a responder, with other handshakes completing with the existing response in the cache as long as it is valid, or with the appropriate communication-error response otherwise (some details omitted ;) ). There are a few other bugs currently open for less severe issues. TIA for your comments! I'm -1 on this, under the assumption that 2.4.x would eventually also turn it on by default (yes, I'm aware of PR 50740, and CABF trying to push this). While enabling it by default on trunk probably doesn't change much (in my experience, very, very few people really compile and run trunk, I would even claim that this applies to http devs, too), I feel that the approach of let's turn it on by default and see how many people run into problems (and bring them up on httpd-users etc.) isn't right. Those interested in achieving a more widespread use should specifically test OCSP stapling with mod_ssl, report their findings, file PRs on Bugzilla (and if possible, also submit suitable patches). The fundamental objection I have to enabling stapling by default in our GA releases is that it would enable a phoning home feature (to the CA's OCSP responders) as a side effect of configuring a certificate. This is a setting I consider unacceptable for software published by the Apache HTTP Server project - the default must be opt-in, not opt-out. I've just become aware of this objection and would like to understand the thinking behind it. Firstly, it seems strange to call this phoning home, a term that _usually_ means connecting to the vendor of the s/w. But more importantly, what harm is there in a server connecting to the OCSP responders for the certificates it is serving? Why is this unacceptable? Because in many organizations it can't because of network / firewall restrictions. If it tries nevertheless by default this causes the following issues with a default configuration: 1. As the network components / firewalls likely simply drop the packages the TCP connect to the OCSP server needs to run into TCP connection timeout which can take quite a while blocking the response back to the client of the webserver. Finding this out can be troublesome. 2. As the webserver will try to connect to the OCSP server quite often and is denied this likely triggers intrusion detection systems and starts all kind of security processes in an organization that thinks that a hacked server tries to connect to the outside world. Although we are talking about large organizations... if they choose to disable OCSP to their organization, isn't it equally upon them to configure the server to ignore OCSP? Just to be sure I don't miss anything. This is not about disabling OCSP, its about disabling OCSP stapling by default. Maybe I have a wrong understanding of OCSP stapling, but to me stapling only provides performance improvements, not security improvements for the client as the client still could connect to the OCSP URL given in the cert directly and get the answer from there. If the response is stabled it does not need to (with the same level of security) and saves itself a roundtrip to the OCSP server of the CA and the OCSP server of the CA a request to process. These are the same organization whose management are often those targeted by malware anyways. It's on them if they choose to ignore what few security measures are available to the less savvy end user. Again I don't get what this has to do with malware attacks
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On Wed, Jul 1, 2015 at 8:54 AM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote: -Ursprüngliche Nachricht- Von: benlau...@gmail.com [mailto:benlau...@gmail.com] Im Auftrag von Ben Laurie Gesendet: Mittwoch, 1. Juli 2015 14:27 An: dev@httpd.apache.org Betreff: Re: [RFC] Enable OCSP Stapling by default in httpd trunk On 1 November 2014 at 09:05, Kaspar Brand httpd-dev.2...@velox.ch wrote: On 30.10.2014 15:51, Jeff Trawick wrote: IMO the present concerns with OCSP Stapling are: * not so clear that it has seen enough real-world testing; commented out sample configs and better documentation will help, as will enabling by default in trunk (just a little?) * related bugs 57121 and 57131 A simple way to help with the broader issue raised in 57131, as well as fix 57121, is to not hold the global mutex while communicating with a responder, with other handshakes completing with the existing response in the cache as long as it is valid, or with the appropriate communication-error response otherwise (some details omitted ;) ). There are a few other bugs currently open for less severe issues. TIA for your comments! I'm -1 on this, under the assumption that 2.4.x would eventually also turn it on by default (yes, I'm aware of PR 50740, and CABF trying to push this). While enabling it by default on trunk probably doesn't change much (in my experience, very, very few people really compile and run trunk, I would even claim that this applies to http devs, too), I feel that the approach of let's turn it on by default and see how many people run into problems (and bring them up on httpd-users etc.) isn't right. Those interested in achieving a more widespread use should specifically test OCSP stapling with mod_ssl, report their findings, file PRs on Bugzilla (and if possible, also submit suitable patches). The fundamental objection I have to enabling stapling by default in our GA releases is that it would enable a phoning home feature (to the CA's OCSP responders) as a side effect of configuring a certificate. This is a setting I consider unacceptable for software published by the Apache HTTP Server project - the default must be opt-in, not opt-out. I've just become aware of this objection and would like to understand the thinking behind it. Firstly, it seems strange to call this phoning home, a term that _usually_ means connecting to the vendor of the s/w. But more importantly, what harm is there in a server connecting to the OCSP responders for the certificates it is serving? Why is this unacceptable? Because in many organizations it can't because of network / firewall restrictions. If it tries nevertheless by default this causes the following issues with a default configuration: 1. As the network components / firewalls likely simply drop the packages the TCP connect to the OCSP server needs to run into TCP connection timeout which can take quite a while blocking the response back to the client of the webserver. Finding this out can be troublesome. 2. As the webserver will try to connect to the OCSP server quite often and is denied this likely triggers intrusion detection systems and starts all kind of security processes in an organization that thinks that a hacked server tries to connect to the outside world. Although we are talking about large organizations... if they choose to disable OCSP to their organization, isn't it equally upon them to configure the server to ignore OCSP? These are the same organization whose management are often those targeted by malware anyways. It's on them if they choose to ignore what few security measures are available to the less savvy end user.
AW: [RFC] Enable OCSP Stapling by default in httpd trunk
-Ursprüngliche Nachricht- Von: benlau...@gmail.com [mailto:benlau...@gmail.com] Im Auftrag von Ben Laurie Gesendet: Mittwoch, 1. Juli 2015 14:27 An: dev@httpd.apache.org Betreff: Re: [RFC] Enable OCSP Stapling by default in httpd trunk On 1 November 2014 at 09:05, Kaspar Brand httpd-dev.2...@velox.ch wrote: On 30.10.2014 15:51, Jeff Trawick wrote: IMO the present concerns with OCSP Stapling are: * not so clear that it has seen enough real-world testing; commented out sample configs and better documentation will help, as will enabling by default in trunk (just a little?) * related bugs 57121 and 57131 A simple way to help with the broader issue raised in 57131, as well as fix 57121, is to not hold the global mutex while communicating with a responder, with other handshakes completing with the existing response in the cache as long as it is valid, or with the appropriate communication-error response otherwise (some details omitted ;) ). There are a few other bugs currently open for less severe issues. TIA for your comments! I'm -1 on this, under the assumption that 2.4.x would eventually also turn it on by default (yes, I'm aware of PR 50740, and CABF trying to push this). While enabling it by default on trunk probably doesn't change much (in my experience, very, very few people really compile and run trunk, I would even claim that this applies to http devs, too), I feel that the approach of let's turn it on by default and see how many people run into problems (and bring them up on httpd-users etc.) isn't right. Those interested in achieving a more widespread use should specifically test OCSP stapling with mod_ssl, report their findings, file PRs on Bugzilla (and if possible, also submit suitable patches). The fundamental objection I have to enabling stapling by default in our GA releases is that it would enable a phoning home feature (to the CA's OCSP responders) as a side effect of configuring a certificate. This is a setting I consider unacceptable for software published by the Apache HTTP Server project - the default must be opt-in, not opt-out. I've just become aware of this objection and would like to understand the thinking behind it. Firstly, it seems strange to call this phoning home, a term that _usually_ means connecting to the vendor of the s/w. But more importantly, what harm is there in a server connecting to the OCSP responders for the certificates it is serving? Why is this unacceptable? Because in many organizations it can't because of network / firewall restrictions. If it tries nevertheless by default this causes the following issues with a default configuration: 1. As the network components / firewalls likely simply drop the packages the TCP connect to the OCSP server needs to run into TCP connection timeout which can take quite a while blocking the response back to the client of the webserver. Finding this out can be troublesome. 2. As the webserver will try to connect to the OCSP server quite often and is denied this likely triggers intrusion detection systems and starts all kind of security processes in an organization that thinks that a hacked server tries to connect to the outside world. Regards Rüdiger
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On 1 November 2014 at 09:05, Kaspar Brand httpd-dev.2...@velox.ch wrote: On 30.10.2014 15:51, Jeff Trawick wrote: IMO the present concerns with OCSP Stapling are: * not so clear that it has seen enough real-world testing; commented out sample configs and better documentation will help, as will enabling by default in trunk (just a little?) * related bugs 57121 and 57131 A simple way to help with the broader issue raised in 57131, as well as fix 57121, is to not hold the global mutex while communicating with a responder, with other handshakes completing with the existing response in the cache as long as it is valid, or with the appropriate communication-error response otherwise (some details omitted ;) ). There are a few other bugs currently open for less severe issues. TIA for your comments! I'm -1 on this, under the assumption that 2.4.x would eventually also turn it on by default (yes, I'm aware of PR 50740, and CABF trying to push this). While enabling it by default on trunk probably doesn't change much (in my experience, very, very few people really compile and run trunk, I would even claim that this applies to http devs, too), I feel that the approach of let's turn it on by default and see how many people run into problems (and bring them up on httpd-users etc.) isn't right. Those interested in achieving a more widespread use should specifically test OCSP stapling with mod_ssl, report their findings, file PRs on Bugzilla (and if possible, also submit suitable patches). The fundamental objection I have to enabling stapling by default in our GA releases is that it would enable a phoning home feature (to the CA's OCSP responders) as a side effect of configuring a certificate. This is a setting I consider unacceptable for software published by the Apache HTTP Server project - the default must be opt-in, not opt-out. I've just become aware of this objection and would like to understand the thinking behind it. Firstly, it seems strange to call this phoning home, a term that _usually_ means connecting to the vendor of the s/w. But more importantly, what harm is there in a server connecting to the OCSP responders for the certificates it is serving? Why is this unacceptable?
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On 30.10.2014 15:51, Jeff Trawick wrote: IMO the present concerns with OCSP Stapling are: * not so clear that it has seen enough real-world testing; commented out sample configs and better documentation will help, as will enabling by default in trunk (just a little?) * related bugs 57121 and 57131 A simple way to help with the broader issue raised in 57131, as well as fix 57121, is to not hold the global mutex while communicating with a responder, with other handshakes completing with the existing response in the cache as long as it is valid, or with the appropriate communication-error response otherwise (some details omitted ;) ). There are a few other bugs currently open for less severe issues. TIA for your comments! I'm -1 on this, under the assumption that 2.4.x would eventually also turn it on by default (yes, I'm aware of PR 50740, and CABF trying to push this). While enabling it by default on trunk probably doesn't change much (in my experience, very, very few people really compile and run trunk, I would even claim that this applies to http devs, too), I feel that the approach of let's turn it on by default and see how many people run into problems (and bring them up on httpd-users etc.) isn't right. Those interested in achieving a more widespread use should specifically test OCSP stapling with mod_ssl, report their findings, file PRs on Bugzilla (and if possible, also submit suitable patches). The fundamental objection I have to enabling stapling by default in our GA releases is that it would enable a phoning home feature (to the CA's OCSP responders) as a side effect of configuring a certificate. This is a setting I consider unacceptable for software published by the Apache HTTP Server project - the default must be opt-in, not opt-out. Kaspar
[RFC] Enable OCSP Stapling by default in httpd trunk
IMO the present concerns with OCSP Stapling are: * not so clear that it has seen enough real-world testing; commented out sample configs and better documentation will help, as will enabling by default in trunk (just a little?) * related bugs 57121 and 57131 A simple way to help with the broader issue raised in 57131, as well as fix 57121, is to not hold the global mutex while communicating with a responder, with other handshakes completing with the existing response in the cache as long as it is valid, or with the appropriate communication-error response otherwise (some details omitted ;) ). There are a few other bugs currently open for less severe issues. TIA for your comments! Index: docs/conf/extra/httpd-ssl.conf.in === --- docs/conf/extra/httpd-ssl.conf.in (revision 1635504) +++ docs/conf/extra/httpd-ssl.conf.in (working copy) @@ -9,7 +9,7 @@ # consult the online docs. You have been warned. # # Required modules: mod_log_config, mod_setenvif, mod_ssl, -# socache_shmcb_module (for default value of SSLSessionCache) +# socache_shmcb_module (default SSLSessionCache and SSLStaplingCache) # # Pseudo Random Number Generator (PRNG): @@ -81,13 +81,13 @@ # How-To for more information. # # Enable stapling for all SSL-enabled servers: -#SSLUseStapling On +SSLUseStapling On # Define a relatively small cache for OCSP Stapling using # the same mechanism that is used for the SSL session cache # above. If stapling is used with more than a few certificates, # the size may need to be increased. (AH01929 will be logged.) -#SSLStaplingCache shmcb:ssl_stapling(32768) +SSLStaplingCache shmcb:ssl_stapling(32768) # Seconds before valid OCSP responses are expired from the cache #SSLStaplingStandardCacheTimeout 3600 -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Am Thu, 30 Oct 2014 10:51:15 -0400 schrieb Jeff Trawick traw...@gmail.com: # Define a relatively small cache for OCSP Stapling using # the same mechanism that is used for the SSL session cache # above. If stapling is used with more than a few certificates, # the size may need to be increased. (AH01929 will be logged.) Could this be made a bit more precise? What's more than a few certificates? Preferrably there should be some rough calculation (certs*Xkb) that gives a safe margin for the space. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 signature.asc Description: PGP signature
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On Thu, Oct 30, 2014 at 4:54 PM, Hanno Böck ha...@hboeck.de wrote: Am Thu, 30 Oct 2014 10:51:15 -0400 schrieb Jeff Trawick traw...@gmail.com: # Define a relatively small cache for OCSP Stapling using # the same mechanism that is used for the SSL session cache # above. If stapling is used with more than a few certificates, # the size may need to be increased. (AH01929 will be logged.) Could this be made a bit more precise? What's more than a few certificates? Preferrably there should be some rough calculation (certs*Xkb) that gives a safe margin for the space. I don't know if a tighter language will actually help. * The 32K and few roughly matches the largest per-certificate responses that mod_ssl can handle. So that's the safe margin. * I have read that the responses can vary from a few hundred bytes to a few K bytes, and I have seen a few in the 500-600 byte range, so I expect that for most cases there will actually be a huge margin with the default config. With LogLevel TraceN you can see the cache stores for the responses. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 -- Born in Roswell... married an alien... http://emptyhammock.com/