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.
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.
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?
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).
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.
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.
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.
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.
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.
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:
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.
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.
Unable to click through certificate warnings = completely inaccessible when there is an issue with certificate validation. Look at the shiny new attack surface!
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.
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.
What are you getting at? As far as I know, OMB doesn't require key escrow, so it almost certainly doesn't happen at scale. I'd imagine that if an intelligence service asked an agency for keymat, they'd happily provide it. I know that I wouldn't have a problem with someone from old St. Elizabeths Hospital or Fort Meade or Crystal City asking me for stuff, especially since the order to co-ooperate with DHS or NSA or the Pentagon would come through the agency's chain of command.
That said, DHS runs an intrusion prevention system called EINSTEIN, whose mission is to protect all federal civilian computer networks:
Using EINSTEIN _is_ mandated by OMB, so if you're worried about the U.S. federal government snooping on your communications with the U.S. federal government, I don't know what to tell you.
.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.
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.
[+] [-] Bartweiss|9 years ago|reply
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|9 years ago|reply
[+] [-] konklone|9 years ago|reply
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...
[+] [-] scrollaway|9 years ago|reply
[+] [-] tomschlick|9 years ago|reply
[+] [-] austincheney|9 years ago|reply
[+] [-] 3pt14159|9 years ago|reply
My email is in my profile :)
[+] [-] t0mas88|9 years ago|reply
[+] [-] konklone|9 years ago|reply
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.
[+] [-] tedunangst|9 years ago|reply
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.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] foota|9 years ago|reply
[+] [-] Godel_unicode|9 years ago|reply
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|9 years ago|reply
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.
[+] [-] hannibalhorn|9 years ago|reply
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|9 years ago|reply
> 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...
[+] [-] excalibur|9 years ago|reply
[+] [-] konklone|9 years ago|reply
[+] [-] cakeface|9 years ago|reply
[+] [-] noahkunin|9 years ago|reply
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.
[+] [-] carlosdp|9 years ago|reply
[+] [-] mikeash|9 years ago|reply
[+] [-] xenophonf|9 years ago|reply
That said, DHS runs an intrusion prevention system called EINSTEIN, whose mission is to protect all federal civilian computer networks:
https://en.wikipedia.org/wiki/Einstein_(US-CERT_program)
Using EINSTEIN _is_ mandated by OMB, so if you're worried about the U.S. federal government snooping on your communications with the U.S. federal government, I don't know what to tell you.
[+] [-] brainfire|9 years ago|reply
I can vouch personally that at least one civilian department doesn't do this.
[+] [-] besselheim|9 years ago|reply
[+] [-] profmonocle|9 years ago|reply
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.
[+] [-] prodtorok|9 years ago|reply
[+] [-] konklone|9 years ago|reply
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/