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

41–50 of 82 posts

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

#41

Post by pfg »

tedunangst wrote: post #34
pfg wrote: post #32

Earlier quoted context omitted.

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…

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

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

#42

Post by prodtorok »

konklone wrote: post #28
prodtorok wrote: post #26

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

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

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

#43

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

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

#44

Post by Godel_unicode »

pfg wrote: post #40
Godel_unicode wrote: post #35

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.). Backhoe eats the fiber to the ocsp responder and CRL distribution point, CRLs timeout after 24 hours. Boom, as the kids are saying.

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

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

#45

Post by pfg »

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

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/

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

#46

Post by konklone »

hannibalhorn wrote: post #43

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.

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

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

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

#47

Post by konklone »

scrollaway wrote: post #38
konklone wrote: post #2

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

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?

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.

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

#48

Post by konklone »

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

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

#49

Post by hackuser »

tedunangst wrote: post #33
t0mas88 wrote: post #3

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.

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.

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

Don't forget mobile and other platforms, where resources are more constrained.

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

#50

Post by konklone »

tedunangst wrote: post #33
t0mas88 wrote: post #3

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.

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.

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.
Post reply on HN