
Automatic HTTPS Enforcement for New Executive Branch .gov Domains - konklone
https://cio.gov/automatic-https-enforcement-new-executive-branch-gov-domains/
======
Bartweiss
This is fantastic news.

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.

~~~
walrus01
Please name and shame the httpd that's asking for plaintext SSNs... That's
newsworthy and I'm sure some tech journalists will pick it up on a slow day.

~~~
Bartweiss
It was a state jobs site which has since updated to HTTPS. They still suck in
a lot of ways - the required login is SSN, plus an 8-digit (numeric only) PIN.
That's a laughably bad login scheme, but at least they aren't passing it in
the clear.

If I do see it again, is there anything like a clearinghouse for this sort of
complaint?

------
konklone
Co-author of the post here, happy to answer questions. =)

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...](https://18f.gsa.gov/2017/01/04/tracking-the-us-governments-
progress-on-moving-https/)

~~~
austincheney
Does this include DOD? I suspect DOD is probably already doing this, but just
wonder if they fall under the umbrella.

~~~
konklone
DoD does have some .gov domains, so it would affect them in that way. But .mil
is not affected.

------
3pt14159
If anyone works in the Canadian government and wants my input in getting the
political support to make this happen in your department, I've been helping
some departments understand the nature of the risks (some are even paying me
as a consultant!) of MITM attacks. It's taking time, but I'm slowly seeing
improvement. I can give you some tips as to how to properly communicate the
importance of some of these and other measures (like getting monitors like
Appcanary installed to watch for security vulnerabilities).

My email is in my profile :)

------
t0mas88
As a practical question: what is the expected capacity of the preload stores
of browsers? Hundreds of thousands, millions or much more domains? Because at
some point it seems like everyone with moderately high security requirements
may want to have their certificates pinned / preloaded.

~~~
tedunangst
My browser's disk footprint is already over 100MB. What's another X MB?

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.

~~~
konklone
I wouldn't say this is reinventing the CA system. You don't need to trust any
particular browser here. The effect is that web services must offer a secure
HTTPS connection, using the existing CA system (or an enterprise CA, if their
user base is truly all-enterprise), no matter what browser is being used.

~~~
hrjet
> You don't need to trust any particular browser here.

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!

~~~
konklone
What you're trusting the browser for there is the extra protection that
preloading provides, but that's not the whole benefit here. The larger benefit
is that it makes it infeasible for services to neglect to support HTTPS. So,
even if your browser's preload list is busted, the site will be guaranteed to
support HTTPS because of this effort, which you'll still benefit from.

~~~
hrjet
Ah ok. I think I see what you are saying now. As long as a sizeable portion of
browsers support a fresh version of the preloaded list, there is sufficient
customer feedback to push the servers to only support https. Right?

~~~
konklone
Exactly.

------
Godel_unicode
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 this idea part of the discussion?

~~~
konklone
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/](https://https.cio.gov/)

Some rationale for "Why everything?" can be found here:

[https://https.cio.gov/everything/](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.

~~~
Godel_unicode
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

~~~
konklone
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://arxiv.org/abs/1602.07128)

* [https://citizenlab.org/2015/04/chinas-great-cannon/](https://citizenlab.org/2015/04/chinas-great-cannon/)

* [http://www.forbes.com/sites/kashmirhill/2014/10/28/find-out-...](http://www.forbes.com/sites/kashmirhill/2014/10/28/find-out-whether-this-privacy-killing-super-cookie-is-on-your-phone/#31f53f491918)

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...](https://https.cio.gov/guide/#are-federally-operated-certificate-
revocation-services-\(crl,-ocsp\)-also-required-to-move-to-https%3f)

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.

------
hannibalhorn
From what I gather, Let's Encrypt meets the guidelines to be considered
acceptable, but is not really mentioned anywhere, neither in the linked page
nor on https.cio.giv - is there any feeling one way or the other on the use of
Let's Encrypt for .gov?

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.

~~~
konklone
Let's Encrypt isn't specifically mentioned in the post, though the post hits
the underlying point:

> 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...](https://https.cio.gov/certificates/#what-kind-of-certificate-
should-i-get-for-my-domain%3f)

Two GSA programs automate Let's Encrypt to deploy certificates on demand:

* [https://www.digitalgov.gov/2016/09/07/lets-encrypt-those-cna...](https://www.digitalgov.gov/2016/09/07/lets-encrypt-those-cnames-shall-we/)

* [https://cloud.gov/docs/apps/custom-domains/#managed-service-...](https://cloud.gov/docs/apps/custom-domains/#managed-service-method)

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...](https://letsencrypt.org/documents/LE-US-State-Local-SA-Amendment-
Dec-28-2016.pdf)

------
excalibur
Unable to click through certificate warnings = completely inaccessible when
there is an issue with certificate validation. Look at the shiny new attack
surface!

~~~
konklone
If there's an issue with certificate validation, the attack surface is already
open.

~~~
Godel_unicode
You've forgotten that security includes availability, in addition to
confidentiality and integrity. Interesting design choice for the entity which
runs the emergency broadcasting system.

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.

~~~
pfg
I think what konklone was getting at is that any scenario that allows an
attacker to trigger a certificate warning (and effectively taking down the
service) would also allow them to take down the service through other means.
Do you have a scenario in mind that doesn't require either a MitM (who could
just as well block the service) or a compromised client/server (which would
allow the attacker to block access either way)?

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

~~~
pfg
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 for every possible TLS server or client
issue, there are a multitude of other server, network or browser issues that
could have a similar effect.

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

~~~
konklone
Very true. HPKP is not part of this change, and if you look at GSA's guidance
on HPKP, it's cognizant of this risk:

[https://https.cio.gov/certificates/#http-public-key-
pinning](https://https.cio.gov/certificates/#http-public-key-pinning)

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

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

~~~
EdHominem
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?!

~~~
brainfire
It would have to be one of the four people with root.

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.

~~~
EdHominem
> It would have to be one of the four people with root.

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.

~~~
brainfire
> A more-robust system would require multiple malicious agents in various
> organizational silos (security, compliance, management) to fail.

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.

~~~
EdHominem
> They're not. [keys not collected by another agency]

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.

~~~
brainfire
Sorry, I'm not going to continue arguing with you. It's clear you don't
understand the scope of what you're proposing is happening.

~~~
willstrafach
Strangely, many tech folks seem to have normalized some very wild fantasies
about what the NSA does.

~~~
EdHominem
I'm using the NSA as an example of a foe of sufficient capability, not saying
that this is what they do (to our own agencies at any rate.) Someone who can
trojan hardware, suborn any given person, etc.

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.

------
besselheim
It should really be .gov.us rather than a top level domain.

~~~
profmonocle
.gov, .mil, and .edu predate the existence of country-code TLDs. They're a
legacy of when the Internet was a US government funded research project.

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.

~~~
belovedeagle
On the other hand, if we put in that effort now we won't have to listen to
people who know nothing about how the internet came to be, and are indignant
and _shocked_ that the US government should have special treatment, for the
next N decades. Seems almost worth it to me...

------
prodtorok
How has this been enforced? and what about sub-domains?

~~~
konklone
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://](https://) connections, and no clicking through certificate
warnings.

Some more detail on all this here:
[https://https.cio.gov/hsts/](https://https.cio.gov/hsts/)

~~~
prodtorok
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

~~~
konklone
@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](https://agency.gov) to "see" the HSTS header once to get
that coverage. Visiting [https://www.agency.gov](https://www.agency.gov) or
[http://agency.gov](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.

~~~
prodtorok
thanks, ill look into it!

