Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Automatic HTTPS Enforcement for New Executive Branch .gov Domains

cio.gov

Post reply on HN
Print view View original

51–60 of 82 posts

Re: Automatic HTTPS Enforcement for New Executive Branch .gov Domains

#51

Post by pfg »

Godel_unicode wrote: post #44
pfg wrote: post #40

Earlier quoted context omitted.

> You might want to re-read my post more carefully, there is not necessarily an attacker per-se in an availability incident (although there certainly could be. Depends on how evil one wants to think.). 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 discussio…

Is the backhoe/squirrel/hurricane an attacker thus making this an "attack"? Semantics. Availability is part of the attack _surface_, which if we're being pedantic is what was being discussed. ("Look at the shiny new attack surface!") > 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…

> 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.

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.

Re: Automatic HTTPS Enforcement for New Executive Branch .gov Domains

#52

Post by konklone »

Godel_unicode wrote: post #44
pfg wrote: post #40

Earlier quoted context omitted.

> You might want to re-read my post more carefully, there is not necessarily an attacker per-se in an availability incident (although there certainly could be. Depends on how evil one wants to think.). 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 discussio…

Is the backhoe/squirrel/hurricane an attacker thus making this an "attack"? Semantics. Availability is part of the attack _surface_, which if we're being pedantic is what was being discussed. ("Look at the shiny new attack surface!") > 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…

To quote my comment from above - bear in mind that when it comes to plain HTTP, it's not just the system's confidentiality and integrity that you need to weigh against availability: it's the user's confidentiality and integrity.

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.

Re: Automatic HTTPS Enforcement for New Executive Branch .gov Domains

#53

Post by konklone »

prodtorok wrote: post #42
konklone wrote: post #28

Earlier quoted context omitted.

Subdomains generally get automatically included when a second-level domain is preloaded. So, for .gov domains that fall under scope here, their subdomains will all have HTTPS enforced by modern web browsers. Web browsers enforce preloading by considering each domain as having HTTP Strict Transport Security (HSTS) set, and so it gets the strict treatment: only https:// connections, and no clicking through certificate…

I've contracted for a few of the larger agencies and that's just not true. Their DNS's can route sub-domains to several (hundreds) different sites/servers where there is no, and continues to be no, https

@prodtorok - This is one of the nice things about HSTS. The includeSubDomains directive can create automatic client enforcement for all subdomains. If some component of an agency ignores this and doesn't configure HTTPS, they'll find that users of modern browsers won't be able to access the site.

The one downside of includeSubDomains is that, with dynamic HSTS (without preloading), you have to get the user to visit https://agency.gov to "see" the HSTS header once to get that coverage. Visiting https://www.agency.gov or http://agency.gov won't do it.

So another benefit of preloading is that you remove that problem from the table -- browsers will enforce HTTPS for all subdomains, even if the user has never visited the root site. It's a powerful tool, and there is no analogue for other protocols (like IPv6 or DNSSEC) to set policies for an entire zone that you can expect most clients to enforce.

Re: Automatic HTTPS Enforcement for New Executive Branch .gov Domains

#54

Post by Godel_unicode »

pfg wrote: post #41
tedunangst wrote: post #34

Earlier quoted context omitted.

Well, it doesn't have to be an attack per se. Maybe the client's clock is wrong, which actually happens a lot. Or admin error replacing the cert on the server. There are of course lots of ways admin error can take down a server, but https adds some fun possibilities that are easier to trigger and harder to recover from.

I mean, sure, there's more things that can go wrong once you add TLS to the stack. At the same time, there are so many other guns to shoot yourself in the foot with, so why is that we should draw the complexity trade-off line between HTTP and HTTPS? HTTPS seems to be good enough for 50% of all page loads nowadays. There's no active attack scenario here (which I agree would be a concern for critical services!), and fo…

The point of this thread has been that adding additional complexity, whatever its form, makes services more fragile. You might not be aware of this, but there was recently a Treasury CA delegated from the Federal Common Policy root CA whose cert expired. This caused every system downstream to have to go through and update their CA bundles. There was significant pain because systems with hsts enabled trying to connect to web services with the wrong cert bundle caused exactly the type of outage we've been discussing. This is not a hypothetical, there were systems with days/weeks of downtime caused by (mostly) human error. The fact that other things can go wrong too does not mean that things going wrong because of HTTPS isn't a problem. It's a trade-off, like everything in security.

Managing certs is work. People get it wrong sometimes. Mandatory hsts means no "just click allow" safety net. This decision takes away the ability to accept that risk for systems where availability is more important.

Re: Automatic HTTPS Enforcement for New Executive Branch .gov Domains

#55

Post by Godel_unicode »

konklone wrote: post #48
Godel_unicode wrote: post #30

I said something similar in a reply below, but I find it interesting that this amounts to a .Gov-wide decision that availability is always less important than confidentiality and integrity. While that's probably valid in the main, is that always true? FEMA/NOAA spring to mind. As does IRS guidance, especially since those documents should have digital signatures themselves for an additional layer of integrity. Was thi…

Bear in mind that when it comes to plain HTTP, it's not just the system's confidentiality and integrity that you need to weigh: it's the user's confidentiality and integrity. That's a larger moral responsibility, in my opinion. These issues were already worked through for the executive branch as part of the White House HTTPS policy published in June 2015: https://https.cio.gov/ Some rationale for "Why everything?" ca…

How is the user's C/I adversely affected by allowing FEMA to have a non-https subdomain for emergency alerts? That's a super easy addition to the policy: HTTPS everywhere except for GET requests to alerts.fema.gov.

I assume you know, but in case you don't, hostnames are typically outside the envelope for HTTPS. So this hypothetical GET already leaks that it's going to alerts.fema.gov. Then realize that the HTTPS cipher suites positively identified the HTTPS library being used, and packet details + origin IP leak the OS.

Edit: I'll even do you one better. Have the policy be HTTPS everywhere and HSTS everywhere but alerts.fema.gov

Re: Automatic HTTPS Enforcement for New Executive Branch .gov Domains

#56

Post by EdHominem »

brainfire wrote: post #18
cakeface wrote: post #14

What are the odds that the private keys for all of the .gov domains are also sent to the NSA? I guess if you are worried about another nation spying on your traffic you would be fine. I would expect that all of this traffic is decryptable by NSA though.

I think it's safe to assume that would be impossible to keep secret. The number of people that would need to be "in on it" is huge. I can vouch personally that at least one civilian department doesn't do this.

Do you really have a policy that would survive an NSA-directed evil-sysadmin attack from any of the participants in your chain of trust? As a civilian branch of the government?

It's pretty hard to setup a system that would survive an powerful adversary who simply didn't know your passwords, have access to your safes, etc. But to then make that system hardened against a malicious insider with get-of-of-jail card?!

Re: Automatic HTTPS Enforcement for New Executive Branch .gov Domains

#57

Post by tedunangst »

pfg wrote: post #41
tedunangst wrote: post #34

Earlier quoted context omitted.

Well, it doesn't have to be an attack per se. Maybe the client's clock is wrong, which actually happens a lot. Or admin error replacing the cert on the server. There are of course lots of ways admin error can take down a server, but https adds some fun possibilities that are easier to trigger and harder to recover from.

I mean, sure, there's more things that can go wrong once you add TLS to the stack. At the same time, there are so many other guns to shoot yourself in the foot with, so why is that we should draw the complexity trade-off line between HTTP and HTTPS? HTTPS seems to be good enough for 50% of all page loads nowadays. There's no active attack scenario here (which I agree would be a concern for critical services!), and fo…

If I screw up max connections or keep alive or some such in nginx.conf I can revert that change with downtime limited to the duration of the bad change. Screw up HPKP with a bad cert roll and you can't just revert. Users will be bifurcated into before and after groups, and you can't fix that without waiting it out.

Re: Automatic HTTPS Enforcement for New Executive Branch .gov Domains

#58

Post by prodtorok »

konklone wrote: post #53
prodtorok wrote: post #42

Earlier quoted context omitted.

I've contracted for a few of the larger agencies and that's just not true. Their DNS's can route sub-domains to several (hundreds) different sites/servers where there is no, and continues to be no, https

@prodtorok - This is one of the nice things about HSTS. The includeSubDomains directive can create automatic client enforcement for all subdomains. If some component of an agency ignores this and doesn't configure HTTPS, they'll find that users of modern browsers won't be able to access the site. The one downside of includeSubDomains is that, with dynamic HSTS (without preloading), you have to get the user to visit h…

thanks, ill look into it!

Re: Automatic HTTPS Enforcement for New Executive Branch .gov Domains

#59

Post by pfg »

tedunangst wrote: post #57
pfg wrote: post #41

Earlier quoted context omitted.

I mean, sure, there's more things that can go wrong once you add TLS to the stack. At the same time, there are so many other guns to shoot yourself in the foot with, so why is that we should draw the complexity trade-off line between HTTP and HTTPS? HTTPS seems to be good enough for 50% of all page loads nowadays. There's no active attack scenario here (which I agree would be a concern for critical services!), and fo…

If I screw up max connections or keep alive or some such in nginx.conf I can revert that change with downtime limited to the duration of the bad change. Screw up HPKP with a bad cert roll and you can't just revert. Users will be bifurcated into before and after groups, and you can't fix that without waiting it out.

Oh, HPKP is definitely something you'll want to think about hard before committing to. Getting a publicly-trusted certificate from any of the myriad of CAs out there, on the other hand, is no rocket science.

Re: Automatic HTTPS Enforcement for New Executive Branch .gov Domains

#60

Post by konklone »

Godel_unicode wrote: post #55
konklone wrote: post #48

Earlier quoted context omitted.

Bear in mind that when it comes to plain HTTP, it's not just the system's confidentiality and integrity that you need to weigh: it's the user's confidentiality and integrity. That's a larger moral responsibility, in my opinion. These issues were already worked through for the executive branch as part of the White House HTTPS policy published in June 2015: https://https.cio.gov/ Some rationale for "Why everything?" ca…

How is the user's C/I adversely affected by allowing FEMA to have a non-https subdomain for emergency alerts? That's a super easy addition to the policy: HTTPS everywhere except for GET requests to alerts.fema.gov. I assume you know, but in case you don't, hostnames are typically outside the envelope for HTTPS. So this hypothetical GET already leaks that it's going to alerts.fema.gov. Then realize that the HTTPS ciph…

Yes, I do know that hostnames are typically outside the HTTPS envelope. However, user-agent is not, and would be exposed (and could then possibly be correlated to other HTTPS traffic from the same IP address). Also, potentially cookies from a previous session -- even a previous HTTPS session -- could be exposed, depending on how careless the server operator is. (You can set flags to make sure cookies only go over HTTPS, but that doesn't always happen.)

From an integrity perspective, connecting to alerts.fema.gov over HTTP does potentially subject the user to code injection attacks. Those do happen:

* https://arxiv.org/abs/1602.07128

* https://citizenlab.org/2015/04/chinas-great-cannon/

* http://www.forbes.com/sites/kashmirhill/2014/10/28/find-out-...

Now, are any of these likely to happen on an arbitrary request to alerts.fema.gov? Maybe not. (Especially since Verizon has since been fined by the FCC.) But I'm trying to point out that it's not just the service owner whose safety has to be weighed in policies like this.

FWIW, the GSA plan announced in this post is intentionally crafted to be gradual and to avoid breaking things. It only affects future domains, not present ones, and so we'll have plenty of time to see whether being a total hardass about HSTS causes negative effects. Agencies can still do specialized services on their existing domains.

There's also going to have to be some carveout somewhere for specialized services like OCSP/CRL, which are already exempted from the policy mandate that came out in June 2015:

https://https.cio.gov/guide/#are-federally-operated-certific...

But in any case, the push should be, clearly and loudly, towards changing the defaults that browsers and users accept, and I think GSA's change weighs the tradeoffs appropriately in making such a push.

Post reply on HN