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 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 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
On 05.09.2015 12:53, Ben Laurie wrote: > On Sat, 5 Sep 2015 at 09:32 Kaspar Brand wrote: >> I'm also very sceptical that a higher percentage of handshakes with >> stapled responses (how much exactly?) will lead browser vendors to >> switch to hard fail - as the test-sspev.verisign.com example from my >> previous message shows, they could do this for EV today already (even >> Chrome tries querying the OCSP responder in this case). But none of them >> does, often due to the fear of losing market share when being too strict >> in enforcing TLS security (cf. the case of RC4 banning). >> > > I don't know why you think your example shows that - the reason browsers > don't hard fail is because OCSP (or any out of band communication) is > unreliable. Unreliable in what sense, or for what reason? Due to OCSP responders being unreachable, being unable to handle the load, serving flawed responses (like the recent hiccup mentioned in https://twitter.com/GSSystemAlerts/status/634418637835669504), or...? Only the second point can be addressed by stapling, as it simply switches to another method for transmitting the response to the client. > So that either means you fail for sites that are actually > perfectly OK, or you allow an attacker to override revocation (by blocking > OCSP). > > This is why browsers are pushing for OCSP stapling, not because of speed. Taking into account that OCSP responders from the big players are running on fairly robust infrastructure these days (cf. the sr.symcd.com example, aka ocsp.verisign.net, aka ocsp.ws.symantec.com.edgekey.net), I'm not buying the "OCSP is unreliable" statement in this wholesale form. Even assuming that, say, 90% of all handshakes would include stapled responses one day, I'm pretty sure that browsers would come up with other arguments as to why they can't enforce hard-fail. Or perhaps in one or two years, they want everybody to switch to using short-lived certs without OCSP (because "revocation doesn't work" anyway), at which point the "let's get OCSP stapling universally deployed" exercise would become moot. > Certificate Transparency faces the same problem, which is why it only > exists as an in-band mechanism. > > Blocking stapling (and presumably you will also object to CT for similar > reasons) is hurting security. CT is a completely separate topic, but for the sake of completeness: yes, I would object to enabling such a feature in httpd by default, as long as it triggers outgoing connections on the server. That isn't the case for being able to serve SCTs, however: all it takes is httpd/mod_ssl 2.4.8 or later compiled against OpenSSL 1.0.2a or later, an appropriate "BEGIN SERVERINFO FOR..." file and an "SSLOpenSSLConfCmd ServerInfoFile ..." directive in the config (no outgoing connectivity on the server needed, neither permanently nor temporarily). > You've argued that there's no point switching on stapling because browsers > won't pay attention to OCSP anyway. That is not true. They don't pay > attention to OCSP because it is unreliable. If stapling were widely > deployed, then it would be possible to switch on hard fail. Again, the "OCSP is unreliable" statement is just your current claim (unless you can provide real-world measurements showing things like "30% of all OCSP queries fail due to timeouts", "50% of all OCSP checks take more than 3 seconds" or similar). Having used Firefox with security.OCSP.require=true for extended periods of time, I do not agree with the overall assessment of OCSP being unreliable. > Leaving it to admins makes no sense to me - most admins are not acquainted > with the detailed reasons for/against stapling, and are not in a position > to make an informed decision. That's what our documentation is for. Just asserting that admins are too dumb to understand and instead decide on their behalf is an attitude I strongly dislike. Apache httpd is not the same sort of software like browsers for the big (and probably often clueless) masses, where that approach might have its justification. > Someone has to choose the default, and IMO > the ASF should always default to "more secure". Pretty muddy ground - "more secure" in what sense exactly? A server not being dependent on outgoing connectivity for its day-to-day operations is typically more secure than one which regularly needs to fetch data from the outside world. And if stapling is really making servers "more secure", why are www.google.com, mail.google.com or drive.google.com still not providing stapled responses as of today? (same is true for other high-traffic sites like Twitter or FB, JFTR) Kaspar
Bug report for Apache httpd-2 [2015/09/06]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 7483|Ass|Enh|2002-03-26|Add FileAction directive to assign a cgi interpret| | 8713|Inf|Min|2002-05-01|No Errorlog on PROPFIND/Depth:Infinity| | 8867|Opn|Cri|2002-05-07|exports.c generation fails when using a symlink to| |10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i| |11294|New|Enh|2002-07-30|desired vhost_alias option| |11580|Opn|Enh|2002-08-09|generate Content-Location headers | |12033|Opn|Nor|2002-08-26|Graceful restart immediately result in [warn] long| |12680|New|Enh|2002-09-16|Digest authentication with integrity protection | |13599|Inf|Nor|2002-10-14|autoindex formating broken for multibyte sequences| |13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation | |14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR| |14496|New|Enh|2002-11-13|Cannot upgrade any version on Windows. Must uninst| |14922|Inf|Enh|2002-11-28| is currently hardcoded to 'apache2' | |15719|Inf|Nor|2002-12-30|WebDAV MOVE to destination URI which is content-ne| |16761|Inf|Nor|2003-02-04|CustomLog with pipe spawns process during config | |16802|New|Enh|2003-02-05|Additional AllowOverride directive "Restrict" | |16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.| |17107|New|Min|2003-02-16|Windows should not install printenv | |17114|New|Enh|2003-02-17|Please add strip and install-strip targets to Make| |17244|Ass|Nor|2003-02-20|./configure --help gives false information regardi| |17497|Opn|Nor|2003-02-27|mod_mime_magic generates incorrect response header| |18325|New|Enh|2003-03-25|PAM support for suEXEC| |18334|Inf|Cri|2003-03-25|Server crashes when authenticating users against L| |18497|New|Min|2003-03-30|configure --help gives wrong default for sysconfdi| |19043|New|Min|2003-04-15|Interesting interaction between cern_meta module a| |19670|New|Enh|2003-05-05|content type header supplied upon PUT is thrown aw| |20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment | |21253|New|Nor|2003-07-01|Mime magic doesn't continue if type is specifed fo| |21260|New|Nor|2003-07-02|CacheMaxExpire directive not enforced ! | |21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut| |22138|Inf|Cri|2003-08-05|Webdav is not preccessing special chars right.| |22237|New|Enh|2003-08-08|option to disable ServerSignature on index pages | |22484|Opn|Maj|2003-08-16|semaphore problem takes httpd down| |22686|Opn|Nor|2003-08-25|ab: apr_poll: The timeout specified has expired (7| |22898|Opn|Nor|2003-09-02|nph scripts with two HTTP header | |23167|Inf|Cri|2003-09-14|--enable-layout never goes to apr apr-util| |23181|New|Nor|2003-09-15|Status 304 (Not modified) and chunking leads to an| |23238|New|Cri|2003-09-18|non-async-signal-safe operations from signal handl| |23330|New|Enh|2003-09-22|Enhance ApacheMonitor to view and control Tomcat s| |23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54| |24031|New|Enh|2003-10-23|Passphrase protected private key in SSLProxyMachin| |24095|Opn|Cri|2003-10-24|ERROR "Parent: child process exited with status 32| |24437|Opn|Nor|2003-11-05|mod_auth_ldap doubly-escapes backslash (\) charact| |24890|Opn|Nor|2003-11-21|Apache config parser should not be local aware ( g| |25014|New|Enh|2003-11-26|A flexible interface for mod_log_config | |25201|New|Enh|2003-12-04|Provide Cache Purge operation | |25240|Inf|Enh|2003-12-05|SSL Library Error: 336105671 logged as information| |25435|New|Enh|2003-12-11|sethandler and directoryindex not playing nice| |25469|Opn|Enh|2003-12-12|create AuthRoot for defining paths to auth files | |25484|Ass|Nor|2003-12-12|Non-service Apache cannot be stopped in WinXP | |25543|Inf|Nor|2003-12-15|mod_proxy_ajp overwrites existing response headers| |25667|New|Nor|
