Why we use HTTPS for every .gov website we make
18f.gsa.gov
18f.gsa.gov
Edit: not all their sites are doing HTTPS right :-/ 18F developed https://www.notalone.gov and this site has quite a few security issues: https://www.ssllabs.com/ssltest/analyze.html?d=notalone.gov&...
Because bureaucracy, we're still waiting on a replacement SHA-2 cert, which once installed will bring our score up to an A+ like this:
https://www.ssllabs.com/ssltest/analyze.html?d=staging.18f.u...
We're changing up processes internally that will speed things up. The subject of a future post!
EDIT: And yeah, we're aware of the notalone.gov issues. There's some legacy infrastructure there, but we'll try to get it fixed up. Our future sites will be stronger.
Bingo. HTTPS only is a much better way to operate web properties these days -- the only downside is a fairly marginal investment of money and time.
What's interesting is to see the headaches people experience with mixed content warnings/errors before they move to the Light Side of the Force (I've been at places where this is a substantial undertaking/roadblock).
Another reason to add to the list: not having to repeatedly ask the user for permission to access advanced HTML5 APIs. Stuff like streaming media, GPS location, background notifications, and speech recognition. If you're making an HTML5 SPA, HTTPS is essential.
The latency increased, but it doesn't have to be drastic. Ilya Grigorik has a great piece on how to get the handshake down:
https://www.igvita.com/2013/12/16/optimizing-nginx-tls-time-...
We turn on as much of that stuff as we can for our servers, and I'm pretty happy with it.
Dated May 28, 2014
If you don't have an account:
"So at this moment we cannot say whether mod_ssl is going to be a valid crypto module in FIPS mode under RHEL-6 although this is the intent."
That may have changed, and contradict other sources on redhat.com. There are a lot more KB articles on FIPS since the last time I really dug into it over a year ago.
Edit, yes, it looks like it was mod_nss only until the release of RHEL 5.9 last Jan. RHEL-6 was ongoing, but it looks like they claim mod_ssl will work now in other places in the knowledge-base.
You can't even use FIPS in Ubuntu/Debian at all: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/95001
FIPS is just one area where it seems like there's a lot of contradictory information for federal IT. After doing the FedRAMP dance, and reading things to the letter, we stopped working towards it and partnered with one of the vendors that got it first. Their remote access was plain text VNC, 8 character password max. I would say I was surprised the paperwork matters more than real security, but I wasn't.
This is one of the problems with Government and hopefully something that will change. All that is done is piece together bits of what outside vendors have put together and the piecing together is normally done by contractors.
You make a RPM and you deploy it like you would any other package. Yes it is a best practice, in fact the people at Red Hat do the _exact_ same thing, the difference is they have the technical capability to make those kinds of changes, as do most people in the commercial IT sector. The government is the one place where they call it IT when its really just glorified procurement.
However thats not even the problem as you stated its supported just fine. It has been for almost 9 years. The bigger issue is there was a perception is wasn't and instead of working to see what reality was people just did nothing.
Exactly the expectations that 18F would like to change.
You say that as if the certification part itself is remotely quick, predictable, or easy.
- for very high traffic websites HTTPS costs a lot of money. .gov sites are not very high traffic.
- When you have such high traffic you also have a bunch of old winxp and similar clients. These dont work fast on HTTPS and dont work without sslv3 and what not.
So while HTTPS with safe settings works in most cases it doesnt work in all cases.
https://www.imperialviolet.org/2010/06/25/overclocking-ssl.h...
http://blog.codinghorror.com/should-all-web-traffic-be-encry...
Although you may argue that if you are a CDN, encryption can be a significant portion of your costs.
Also, Jeff Atwood writes following:
> Of course, there's no reason to encrypt traffic for anonymous, not-logged-in users, and Twitter doesn't. You get a plain old HTTP connection until you log in, at which point they automatically switch to HTTPS encryption. Makes sense.
Today we know that it is no longer a valid point. TOR users can be deanonimized by injecting traffic into plain HTTP connections. Upgrade to HTTPS seems to be fixing that. So we really should use HTTPS by default and HTTP only in very well articulated cases.
.gov sites can be very high traffic. Think weather, social security, health care, immigration, visas...
> - When you have such high traffic you also have a bunch of old winxp and similar clients. These dont work fast on HTTPS and dont work without sslv3 and what not.
SSLv3 only kills IE6, which is doable. And it's okay if very old clients work slowly with HTTPS -- those clients have far more problems than just slow HTTPS.
Killing IE6 and some others (java clients, etc.) is not always doable and thats the point. its doable for many but not all.
Probably not the best way, but earlier this year I spent about an hour on the phone with CC of IRS telling them that irs.gov should be behind HTTPS with proper certs. They mentioned that all the pages with sensitive information are behind HTTPS. Simple documents and forms are not that important I guess. As you can see it's still an issue.
As long as 90 percent of all websites keep using analytics, authorities only have to go to one place with their warrant to get more or less your complete surf history. And by adding SSL to your site you make things like Privoxy useless.
I think its strange no one has pointed this out in the SSL hysteria going on right now.
I think that's a totally fair point. Our use of Google Analytics isn't changing any time soon, but we do plan to add a third-party disclosure page that makes it clear what third parties have some window into our visitors' browsing:
https://github.com/18F/18f.gsa.gov/issues/293
This includes otherwise invisible things, like our host, Amazon, and (until we implement OCSP stapling, which is happening soon) our CA during revocation checking (in some browsers).
FWIW, we do turn on the Google Analytics anonymization flag, which instructs Google to chop off the last IP triplet before they write the data into their database. Of course, that depends on trusting Google to keep their promise, but it's something.
Over a year ago, I came across a vulnerable .gov site that was first reported in a news.com article from 2005! Sadly, it's still vulnerable today. The author of the original piece states they contacted the Department of Labor back in '05, who responded that they were 'working to address the issue.' Before I wrote the blogpost, I tried getting some attention too, but never got a response. It's now been 9 years, and the site is still vulnerable.
http://jarmoc.com/blog/2013/10/14/open-redirect-in-gov-for-e...
.gov sites are littered with trivial vulns that never seem to get addressed when reported. HTTPS is great and all, but it's far from the only thing that needs to be done in .gov.
That's one of the things we're very much focused on fixing. While we can't go in and change every federal government website out there, we can work to ensure that the security of the platforms we are working on is tight as possible. 18F is working with a number of agencies (see https://18f.gsa.gov/dashboard/ for the full list), and our hope is that we can be a force multiplier in security best practices throughout government.
Furthermore, we take responsible disclosure very seriously, and welcome any feedback through our email (18f@gsa.gov). We should probably take this up a notch and have a dedicated security inbox that goes directly to our core security team.
The problem, from my perspective, is that NO ONE is responsible for everything in the .gov namespace. Trying to sort out an appropriate security contact, especially for relatively minor vulns like this (though it's likely also reflected cross site scripting on benefits.gov) is a nightmare.
Another example involves some work I did while at a previous employer: https://web.archive.org/web/20131114050720/http://www.secure...
I definitely think you're right that a dedicated security inbox would be helpful. Even better would be a dedicated .gov-wide security inbox. I don't know how difficult it would be to establish something like that, but it would give security minded folks who care about improving things an outlet for sharing these sorts of details, and hopefully help get things fixed.
Actually, the Department of Homeland Security is responsible for the security of .gov (at least in theory). I don't think they have unilateral directive authority to enforce that, however, which is a big problem. But maybe reporting the issue to DHS (whatever their cyber security division is) can rattle something loose.
In many cases, they've been prevented from hiring technical staff for a decade or longer so it's not uncommon to find projects which are entirely on life-support, subject to a contract which would require expensive (in both time and money) amendments, etc. The person responsible likely knows about the problem but have zero ability to either fix it directly or get someone else to do.
The other thing you tend to find are poorly considered policies with serious unintended consequences – i.e. for alleged performance/security reasons all traffic is required to go through an agency-wide load-balancer but they didn't buy the SSL module / it's already at capacity and nobody is willing to authorize an exception. (Bonus points if the old single-point-of-failure is scheduled to be replaced by a shiny new SPOF and no changes are allowed until that overdue project ships)
I sometimes fall into the perspective that HN is mostly a community of startup and tech sector people, so it's good to be reminded that there's a wider community here.
i.e https://www.ssllabs.com/ssltest/analyze.html?d=elis.uscis.dh...
I worked with alot of out of touch people who instead of learning something new would rather just do what they know and keep the status quo. What made it harder was alot of these people were smart and new how to play the game to keep the work favorable to what they already know for various reasons usually contractual. People were very dug in and protective of their piece of the pie. It made collaboration difficult because everyone was seemingly an expert when in actuality they were clueless and googling like everyone else.
I wish you good luck 18f you are gonna need it.
But the government is inescapably bad at IT today and seemingly has been since the World Wide Web was first launched.
I hope that can change too, but I don't see that happening as long as the divergence between civilian sector pay and government benefits remains so crazy. This has sucked much (though not all) of the best technical talent (and worse, tech-savvy managers) out of the public sector. Without a critical mass, all of your really skilled geeks in government find it almost impossible to advocate for the right answer, and the policy makers and supervisors are usually not able to tell the difference between the right answer and other, non-feasible, courses of action proposed by the unskilled geeks in government.
To top that off, when the government can't build things using civil servants alone they have to fall back to contractors, but our contracting processes are so insane that it doesn't surprise me at all that our government contracting officers find it impossible to hire and oversee the best companies to deliver and maintain a working project. There have been successes but IMHO when that has happened, it's because the contracting officer has blindly stumbled into a decent contractor.
I'm excited for 18F because a lot of the problem comes down to educating our public sector middle management into what's possible and what's not possible. By demonstrating by example and by explanation of what's already possible in current rules, 18F can boost the stock of the buried geeks hiding out in many of our government agencies.
You nailed it.
I partially blame apps like word and Gmail. When you type in www into a Word document, for example, it will convert it to a link without the https. I've enabled some of our servers to automatically redirect to https but when you are working with a few dozen web servers it gets cumbersome.
Yeah, sometimes. But that's also why we enable HSTS on our stuff, so that that's not relevant. We also just pushed the first .gov domains into the Chrome HSTS preload list a week and a half ago:
https://chromium.googlesource.com/chromium/src/+/af1870543d1...
You have to submit a paper form, two forms of photo ID, references...
To top it all off they snail-mail you the access code to then go online and download your digital certificate. Very archaic.
Has TLS 1.2 intolerance.
The switch to HPACK for header compression resolved this. SPDY/HTTP2 has no currently known security flaws.
https://github.com/18F/tls-standards/blob/master/configurati...
When SPDY 4 or HTTP/2 make their way into an nginx module, we'll upgrade, and turn header compression back on.
Or maybe the sentence is a disaster...
If only the .gov space were shifting at the same rate! That sense of inevitability and momentum you sense in the private sector is not so widely present inside the US government. Posts like this have two audiences: outside folks like you, and my colleagues around the rest of the .gov world.
For reference, 18F got the first .gov domains added to the Chrome HSTS preload list less than 2 weeks ago:
https://chromium.googlesource.com/chromium/src/+/af1870543d1...
Also sadly, yes you would think some progress would have started years ago.
Yes, just like those involved with government. Ha!