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

21–30 of 82 posts

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

#21

Post by noahkunin »

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.

Gov employee here (18F).

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.

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

#22

Post by walrus01 »

austincheney wrote: post #13
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...

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

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.

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

#24

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

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

#25

Post by konklone »

excalibur wrote: post #23

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

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

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

#27

Post by konklone »

dragonwriter wrote: post #20
konklone wrote: post #9

Earlier quoted context omitted.

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.

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

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

We (18F, me) personally measured at least 26,000 (though some of these are used as redirects or are just error pages, etc.).

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

#28

Post by konklone »

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

Some more detail on all this here: https://https.cio.gov/hsts/

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

#29

Post by Godel_unicode »

konklone wrote: post #25
excalibur wrote: post #23

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

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

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.

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

#30

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

Post reply on HN