Backhoe eats the fiber to the ocsp responder and CRL distribution point, CRLs timeout after 24 hours.
Boom, as the kids are saying.
Well, that was the context of this thread. Both the OP and konklone are talking about attack surface. If you want to talk about how running a service via TLS and using HSTS makes HA harder, that's a different discussion.
> Backhoe eats the fiber to the ocsp responder and CRL distribution point, CRLs timeout after 24 hours.
OCSP and CRL is soft-fail by default in all browser I'm aware of. The server is also in control of it via OCSP Stapling, so it has all the tools it needs to keep the server available, assuming proper configuration and monitoring (which is true for a HTTP service as well).
> different discussion
My point is that, no, it's not. The three points of the triad are inextricably linked. More C and/or I means less A (and A tends to be sidelined in favor of C and I these days).
> OCSP and CRL is soft-fail by default in all browser I'm aware of.
Not on government systems they aren't (STIG id: v-44789). Also, if we're going all in on https we should go all in on https.
> ... Stapling
How is the server supposed to get a response to staple if the responder is unavailable?
Also, time. Also, client root of trust. Also, fat-fingering the hostname when the DNS gets updated. Also, public wifi which does mitm...
Bottom line: this is a decision which prioritizes confidentiality and integrity over availability for the entire .gov with (seemingly) no recourse.
Edit: quote from upstream, corrected STIG id
That's a larger moral responsibility, in my opinion. And consider that the fallback to prioritize availability in case of a non-attack cert error (e.g. revocation or expiration) is to ask the user to look at a certificate warning and make a personal trust decision about it. There are precious few users who can safely make that kind of a decision. And even if they "get it right" that time and click through and aren't attacked, you're training users to click through warnings, and helping them subject themselves to attacks in the future.
I would argue that that kind of "availability" is a very weak sort of availability. The government has enough problems with training people to click through certificate warnings (see: https://www.iad.gov) -- intentionally leaving that hole open seems unwise.
I found this description: "By setting this policy to true, the previous behavior is restored and online OCSP/CRL checks will be performed. If the policy is not set, or is set to false, then Chrome will not perform online revocation checks. [...]"
This seems to address the fact that Chrome does not perform OCSP queries at all, instead relying on its CRLSets. However, even back when Chrome did OCSP queries, it was soft-fail (as is every other browser). The "previous behavior" would thus be to query OCSP, but fail silently anyway.
> How is the server supposed to get a response to staple if the responder is unavailable?
OCSP responses from publicly-trusted CAs are typically valid for 10 days, and they're updated at least once every 4 days (IIRC). That'll leave 6 days for the responder to come back online in the worst case (or 6 days to tell everyone about "badidea" in case the CA is nuked from orbit, along with any other publicly-trusted CA the site might switch to). (Let's not forget it's soft-fail, so this is just a theoretical exercise).
> Bottom line: this is a decision which prioritizes confidentiality and integrity over availability for the entire .gov with (seemingly) no recourse.
I'll give you that. I just don't think the availability concerns are bad enough to outweigh the benefits, and they can be mitigated in just about any scenario.