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

61–70 of 82 posts

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

#61

Post by konklone »

tedunangst wrote: post #57
pfg wrote: post #41

Earlier quoted context omitted.

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

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.

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

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

#63

Post by walrus01 »

Bartweiss wrote: post #5

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…

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.

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

#64

Post by brainfire »

EdHominem wrote: post #56
brainfire wrote: post #18

Earlier quoted context omitted.

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.

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

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.

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

#65

Post by EdHominem »

brainfire wrote: post #64
EdHominem wrote: post #56

Earlier quoted context omitted.

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

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

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

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

#66

Post by [deleted] »

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.

[deleted]

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

#67

Post by brainfire »

EdHominem wrote: post #65
brainfire wrote: post #64

Earlier quoted context omitted.

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

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

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

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

#68

Post by profmonocle »

besselheim wrote: post #62

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

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

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

#69

Post by em3rgent0rdr »

profmonocle wrote: post #68
besselheim wrote: post #62

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

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

I think it is a nice little historical artifact. When someone asks why, then can tell the story of the internet's creation.

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

#70

Post by hrjet »

konklone wrote: post #50
tedunangst wrote: post #33

Earlier quoted context omitted.

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.

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

Post reply on HN