11 ms·

Automatic HTTPS Enforcement for New Executive Branch .gov Domains

88 points by konklone 10y ago

konklone 10y ago
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-progress-on-moving-https/ https://18f.gsa.gov/2017/01/04/tracking-the-us-governments-p...
- tomschlick 10y ago
  Any plans to force IPv6 adoption in the same manner?
  - toomuchtodo 10y ago
    IPv6 is pretty low priority compared to comprehensive HTTPS support. Disclaimer: Not USDS/18F, just tech professional.
    - deleted 10y ago
      [deleted]
    - tomschlick 10y ago
      Oh I agree, but the two things can be done at the same time. Especially for new .gov sites. 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.
  - konklone 10y ago
    IPv6 is a federal mandate for agencies: https://www.whitehouse.gov/sites/default/files/omb/assets/egov_docs/transition-to-ipv6.pdf https://www.whitehouse.gov/sites/default/files/omb/assets/eg... And NIST has a dashboard of adoption: https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov
    - tomschlick 10y ago
      Fantastic! Thanks!
- austincheney 10y ago
  Does this include DOD? I suspect DOD is probably already doing this, but just wonder if they fall under the umbrella.
  - konklone 10y ago
    DoD does have some .gov domains, so it would affect them in that way. But .mil is not affected.
  - walrus01 10y ago
    DoD uses https and crypto at the transport layer in SIPR. Lots of "type 1" crypto as well, which is its own special thing with NSA issued hardware crypto keys.
  - deleted 10y ago
    [deleted]
  - stqism 10y ago
    The DoD has a massive PKI system already and makes the assumption users of its sites have the appropriate CAs installed. (Home access typically requires installing a set of them, typically bundled separately or in an installer)
- scrollaway 10y ago
  The blog post is unclear. On a technical level (on the preload list), is the enforcement at the TLD level or is it just a legal requirement to submit all .gov domain names to the preload list? If the latter, any plan to move to the former?
  - konklone 10y ago
    Not quite either one -- it's technical enforcement by the TLD, but still done on a per-domain basis (this doesn't affect state/local .gov domains, or legislative/judicial .gov domains). The dotgov.gov program will forcibly preload new domains, but it's not feasible to just submit ".gov" to the preload list right now.
t0mas88 10y ago
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.
- konklone 10y ago
  I think that's an open question. Right now, it's not the millions, that'd be too much to bundle with browsers. But browsers may well change their delivery mechanism for preload information to allow this to scale higher. 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.
  - dragonwriter 10y ago
    > right now there are all of 5,500 .gov domains 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.
    - konklone 10y ago
      Second level domains. There are waayyyyy more subdomains, as you note. You can see some information and estimates on this here: https://18f.gsa.gov/2017/01/04/tracking-the-us-governments-progress-on-moving-https/ 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.).
- deleted 10y ago
  [deleted]
- foota 10y ago
  Seems like you could use a bloom filter to store whether a domain has a pinned cert, and then use an api provided by the browser to remotely fetch the pinned cert. This has privacy implications, but does step around the storage. Chrome does something similar for CRL, but bloom filters fit that use case better.
Bartweiss 10y ago
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 10y ago
  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 10y ago
    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?
cakeface 10y ago
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.
- carlosdp 10y ago
  I think we can pretty safely assume all information given to the government is in the hands of government agencies, one way or another.
- mikeash 10y ago
  Would you otherwise have an expectation that your data sent to the government would be kept secret from the NSA?
- brainfire 10y ago
  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 10y ago
    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 10y ago
      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.
excalibur 10y ago
Unable to click through certificate warnings = completely inaccessible when there is an issue with certificate validation. Look at the shiny new attack surface!
- konklone 10y ago
  If there's an issue with certificate validation, the attack surface is already open.
  - Godel_unicode 10y ago
    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 10y ago
      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 10y ago
        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.
        Godel_unicode 10y ago
3pt14159 10y ago
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 :)
prodtorok 10y ago
How has this been enforced? and what about sub-domains?
- konklone 10y ago
  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 10y ago
    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
    - pfg 10y ago
      HSTS preloading enforces "includeSubDomains" for all domains that are submitted[1]. It's certainly possible to use HSTS without includeSubDomains, but not preloaded HSTS, and since all new executive branch domains will be preloaded, that means all subdomains will have to support HTTPS as well. [1]: https://hstspreload.org/ https://hstspreload.org/
    - konklone 10y ago
      @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.
Godel_unicode 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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-whether-this-privacy-killing-super-cookie-is-on-your-phone/#31f53f491918 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-certificate-revocation-services-(crl,-ocsp)-also-required-to-move-to-https%3f 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.
hannibalhorn 10y ago
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 10y ago
  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-should-i-get-for-my-domain%3f 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-cnames-shall-we/ https://www.digitalgov.gov/2016/09/07/lets-encrypt-those-cna... * https://cloud.gov/docs/apps/custom-domains/#managed-service-method 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-Amendment-Dec-28-2016.pdf https://letsencrypt.org/documents/LE-US-State-Local-SA-Amend...
besselheim 10y ago
It should really be .gov.us rather than a top level domain.
- profmonocle 10y ago
  .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.
  - em3rgent0rdr 10y ago
    I think it is a nice little historical artifact. When someone asks why, then can tell the story of the internet's creation.
  - belovedeagle 10y ago
    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...
  - konklone 10y ago
    In fact, there are now way more state/local .gov domains (~4,000) than federal .gov domains (~1,300).

88 points by konklone 10y ago

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

tomschlick 10y ago
Any plans to force IPv6 adoption in the same manner?
- toomuchtodo 10y ago
  IPv6 is pretty low priority compared to comprehensive HTTPS support. Disclaimer: Not USDS/18F, just tech professional.
  - deleted 10y ago
    [deleted]
  - tomschlick 10y ago
    Oh I agree, but the two things can be done at the same time. Especially for new .gov sites. 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.
- konklone 10y ago
  IPv6 is a federal mandate for agencies: https://www.whitehouse.gov/sites/default/files/omb/assets/egov_docs/transition-to-ipv6.pdf https://www.whitehouse.gov/sites/default/files/omb/assets/eg... And NIST has a dashboard of adoption: https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov
  - tomschlick 10y ago
    Fantastic! Thanks!
austincheney 10y ago
Does this include DOD? I suspect DOD is probably already doing this, but just wonder if they fall under the umbrella.
- konklone 10y ago
  DoD does have some .gov domains, so it would affect them in that way. But .mil is not affected.
- walrus01 10y ago
  DoD uses https and crypto at the transport layer in SIPR. Lots of "type 1" crypto as well, which is its own special thing with NSA issued hardware crypto keys.
- deleted 10y ago
  [deleted]
- stqism 10y ago
  The DoD has a massive PKI system already and makes the assumption users of its sites have the appropriate CAs installed. (Home access typically requires installing a set of them, typically bundled separately or in an installer)
scrollaway 10y ago
The blog post is unclear. On a technical level (on the preload list), is the enforcement at the TLD level or is it just a legal requirement to submit all .gov domain names to the preload list? If the latter, any plan to move to the former?
- konklone 10y ago
  Not quite either one -- it's technical enforcement by the TLD, but still done on a per-domain basis (this doesn't affect state/local .gov domains, or legislative/judicial .gov domains). The dotgov.gov program will forcibly preload new domains, but it's not feasible to just submit ".gov" to the preload list right now.

t0mas88 10y ago

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.

konklone 10y ago
I think that's an open question. Right now, it's not the millions, that'd be too much to bundle with browsers. But browsers may well change their delivery mechanism for preload information to allow this to scale higher. 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.
- dragonwriter 10y ago
  > right now there are all of 5,500 .gov domains 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.
  - konklone 10y ago
    Second level domains. There are waayyyyy more subdomains, as you note. You can see some information and estimates on this here: https://18f.gsa.gov/2017/01/04/tracking-the-us-governments-progress-on-moving-https/ 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.).
deleted 10y ago
[deleted]
foota 10y ago
Seems like you could use a bloom filter to store whether a domain has a pinned cert, and then use an api provided by the browser to remotely fetch the pinned cert. This has privacy implications, but does step around the storage. Chrome does something similar for CRL, but bloom filters fit that use case better.

Bartweiss 10y ago

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 10y ago
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 10y ago
  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?

cakeface 10y ago

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.

carlosdp 10y ago
I think we can pretty safely assume all information given to the government is in the hands of government agencies, one way or another.
mikeash 10y ago
Would you otherwise have an expectation that your data sent to the government would be kept secret from the NSA?
brainfire 10y ago
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 10y ago
  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 10y ago
    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.

excalibur 10y ago

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

konklone 10y ago
If there's an issue with certificate validation, the attack surface is already open.
- Godel_unicode 10y ago
  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 10y ago
    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 10y ago
      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.
      - Godel_unicode 10y ago

3pt14159 10y ago

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 :)

prodtorok 10y ago

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

konklone 10y ago
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 10y ago
  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
  - pfg 10y ago
    HSTS preloading enforces "includeSubDomains" for all domains that are submitted[1]. It's certainly possible to use HSTS without includeSubDomains, but not preloaded HSTS, and since all new executive branch domains will be preloaded, that means all subdomains will have to support HTTPS as well. [1]: https://hstspreload.org/ https://hstspreload.org/
  - konklone 10y ago
    @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.

Godel_unicode 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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-whether-this-privacy-killing-super-cookie-is-on-your-phone/#31f53f491918 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-certificate-revocation-services-(crl,-ocsp)-also-required-to-move-to-https%3f 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.

hannibalhorn 10y ago

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 10y ago
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-should-i-get-for-my-domain%3f 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-cnames-shall-we/ https://www.digitalgov.gov/2016/09/07/lets-encrypt-those-cna... * https://cloud.gov/docs/apps/custom-domains/#managed-service-method 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-Amendment-Dec-28-2016.pdf https://letsencrypt.org/documents/LE-US-State-Local-SA-Amend...

besselheim 10y ago

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

profmonocle 10y ago
.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.
- em3rgent0rdr 10y ago
  I think it is a nice little historical artifact. When someone asks why, then can tell the story of the internet's creation.
- belovedeagle 10y ago
  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...
- konklone 10y ago
  In fact, there are now way more state/local .gov domains (~4,000) than federal .gov domains (~1,300).