Automatic HTTPS Enforcement for New Executive Branch .gov Domains
cio.gov
cio.gov
It wasn't that long ago that I tried to log into a government site via my SSN, and discovered that the page didn't even permit HTTPS. I was displeased, to say the least; logging in wasn't exactly optional, so it seemed much worse than a business offering poor security.
Permitting HTTPS is obviously the first step, but security shouldn't be limited to people with the expertise to seek it out. I'm really glad to see that something as inescapable as the .gov domain will be pursuing security-by-default.
If I do see it again, is there anything like a clearinghouse for this sort of complaint?
This is a GSA initiative, not an 18F initiative. But 18F has a recent post detailing executive branch progress on HTTPS that may also be relevant:
https://18f.gsa.gov/2017/01/04/tracking-the-us-governments-p...
Disclaimer: Not USDS/18F, just tech professional.
It appears a lot of .gov sites already support IPv6 but I was wondering if it's an official policy or just at the discretion of the tech team.
And NIST has a dashboard of adoption: https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov
My email is in my profile :)
In any case, .gov won't add much to the load -- right now there are all of 5,500 .gov domains, and the rate of adding/removal is on the order of dozens every month at most.
Is that just domains from which web content is hosted, or just second level domains regardless of whether web content is hosted? Because I can't imagine that there are only 5,500 total .gov domains.
https://18f.gsa.gov/2017/01/04/tracking-the-us-governments-p...
We (18F, me) personally measured at least 26,000 (though some of these are used as redirects or are just error pages, etc.).
The ironic thing is we're reinventing the CA system, only now each browser is its own authority, exactly the problem the CA system was trying to solve.
Don't forget mobile and other platforms, where resources are more constrained.
You do need to trust that the particular browser you are using supports preloaded list, and is using the latest updated version of the list, and is not missing any entries!
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 this idea part of the discussion?
These issues were already worked through for the executive branch as part of the White House HTTPS policy published in June 2015:
Some rationale for "Why everything?" can be found here:
https://https.cio.gov/everything/
Personally, I'd say that plain HTTP is insecure enough, and today's internet is hostile enough, that plain HTTP provides a very weak form of "availability". It's on site operators to ensure that when their services and information is available, that it's available in a manner that doesn't subject the user to risk.
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
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.
Certainly one of the biggest headaches of the classic approach is forgetting to renew your certificate on time, a situation which Let's Encrypt effectively avoids.
> GSA provides extensive guidance to agencies on HTTPS deployment at https.cio.gov, and encourages .gov domain owners to obtain low cost or free certificates, trusted by the general public. As a general matter, more expensive certificates do not offer more security value to service owners, and automatic deployment of free certificates can significantly improve service owners’ security posture.
This is also repeated here:
https://https.cio.gov/certificates/#what-kind-of-certificate...
Two GSA programs automate Let's Encrypt to deploy certificates on demand:
* https://www.digitalgov.gov/2016/09/07/lets-encrypt-those-cna...
* https://cloud.gov/docs/apps/custom-domains/#managed-service-...
There's also a USG amendment to the Let's Encrypt Terms of Service that GSA negotiated with them to make it easier for agencies to use it:
https://letsencrypt.org/documents/LE-US-State-Local-SA-Amend...
You're saying you'd prefer for e.g. NOAA to not be able to issue tornado warnings in order to ensure nobody can fake a tornado warning.
The best is when it's a timezone issue and the distant end responds with "I have 0 drift, must be a problem on your end". Crypto is hard, time is hard. Crypto which relies on time...
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.
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
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.
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.
ex:
During an emergency I connect to public wifi because mine is not working. That wifi has a MITM proxy installed by the owner (because they want to server ads over https, it's a developer's wifi and they were testing with something like charles proxy, etc). This page is now unavailable during an emergency. Thus lack of availability without malicious intent.
The general assumption for HSTS is that, in all cases, it's better to be unavailable than have the possibility of compromise. I'm unsure if that's the case for critical services in times of need.
I can vouch personally that at least one civilian department doesn't do this.
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?!
Multiply this by the number of groups that operate a .gov website (it's a lot) compounded by turnover (even more.) And account for the cat-herders needed to organize it and do it every time the private key rotates (no less than yearly for our internet-facing sites.)
There are a lot of ways you could do this on a small scale, but you really can't scale up this particular mechanism and keep it secret.
Or anyone who'd ever gotten access to the computer, or installed a camera near it, etc.
The critical part of that answer though, is "one of the". The system fails if any of the individuals is be malicious. A more-robust system would require multiple malicious agents in various organizational silos (security, compliance, management) to fail.
> every time the private key rotates
Well, if I got in once it probably phones that home for me.
> you really can't scale up this particular mechanism and keep it secret
Well, it isn't secret. We know the NSA intercepts hardware to muck with it, when needed. Much easier even than planting something in your server room explicitly. Also, they wield NSLs compelling silence and cooperation. It's not like being discovered here or there would stop scare or stop them.
It would probably scale pretty well given that this is the extreme; most people just generate keys on the old debian box in the corner.
Yes, and at that point the name for it is "policy". These are our own keys after all- nobody would blink an eye if they were supposed to be collected.
They're not.
Right. I think you're absolutely correct, now. And I fully expect (hope!) that the NSA will one-day come to you with some more-secure hardware and that you will gladly cooperate because as you say - we are all on the same team.
My point is that you can't say what you're saying now. You aren't secure, and you don't have the type of procedures that would ever let you get to more than a 4/10 or so. You don't even see having four independent points of failure as an issue, rather than a benefit.
By promising people that the NSA does not have your organization's keys you're providing the less technical with a false picture.
And maybe, one day, that might matter. You might trick the next leaker into trusting your org as a way to whistle-blow and cause them to be caught by the NSA before they reach the news.
> Yes, and at that point the name for it is "policy". [security procedures]
Yeah, and software is just automated policy. If this is a zero, and that's a zero, etc...
If the guard in the vault runs a non-exploitable policy (ie no "I'm the boss" backdoors) then you can greatly reduce evil-sysadmin attacks.
I was hoping to use a very advanced force as an example to show that things that may sound secure aren't if your attacker has a certain level of resources.
Fwiw, most pen-testers would aso be able to bypass any such casually enacted system too, but that's less obvious so I had hoped to avoid that argument by going with an extreme example.
You're confusing being uninteresting with being safe. (Safety is numbers is irrelevant once you've been selected.)
> Sorry, I'm not going to continue arguing with you.
Stop clicking Reply.
If the operative word is "sent" and "all" the likelihood is zero, as I can assert I've never sent a private key to NSA, and I've made quite a few over the past few years.
That said, carlosdp makes a great point as to how one should behave. Even though not all private keys get shipped to NSA (can't make claims about other teams), the government is very public about other data sharing programs (see https://www.dhs.gov/sites/default/files/publications/privacy... for example).
Even though all government agencies must disclose these types of programs, they are so numerous and often so difficult to decipher, the only rational response is to assume everyone has everything or could have access in the future.
The only way to avoid this is to build zero-knowledge systems on the server side, something I hope you'll see more of in 2017.
That said, DHS runs an intrusion prevention system called EINSTEIN, whose mission is to protect all federal civilian computer networks:
https://en.wikipedia.org/wiki/Einstein_(US-CERT_program)
Using EINSTEIN _is_ mandated by OMB, so if you're worried about the U.S. federal government snooping on your communications with the U.S. federal government, I don't know what to tell you.
You could argue that since the Internet has become a global commercial network, the US should no longer have these special, exclusive TLDs. But switching over would be a ton of work, and there really aren't enough downsides to the US having these domains to justify a change.
It's worth noting that .fed.us exists, although hardly any government sites us it. State/city governments often use .[state].us domains since .gov was originally restricted to the federal government, but that restriction was lifted and it's common to see .gov used for state/local governments now as well.
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 warnings.
Some more detail on all this here: https://https.cio.gov/hsts/
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.