konklone

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

But unless clients or humans do anything in response to the extra OV information, or in response to a lack of the extra OV information, that information has no security value.

No browsers do anything with OV data unless humans manually take action to examine the certificate. So I'm comfortable saying they offer negligible security value.

As it happened, we were migrating production infrastructure to a new service tonight, and had a few minutes of time where the cert was invalid. Sorry about that.

You're right, this is (unfortunately) very common. I wish there were clearer guidelines about this.

The White House Office of Management and Budget publishes IT policies, and they ask for specific URLs with www in front: https://www.whitehouse.gov/sites/default/files/omb/memoranda...

But I don't think they or anyone would care if the www redirected to the root, or vice versa, as long as it eventually got you there.

We (18F/GSA) have been using DHS's tool in production for a few months now, and have fixed various bugs as they've come up.

Before that, pshtt's methodology was replicated in a Ruby tool (site-inspector) that we grafted HTTPS/HSTS detection logic onto, and had that running in production for a year or so.

So in terms of business logic, I think it's pretty mature. If you mean things like having it formally audited or having a dedicated development team, it hasn't gotten there yet. But the more people that use it, the more mature it will get.

And 18F/GSA employee and open source collaborator here. =) Can definitely help answer any questions folks have.

And this is a White House policy, with their official blog post and rationale here: https://www.whitehouse.gov/blog/2015/06/08/https-everywhere-...

"It is critical that federal websites maintain the highest privacy standards for the users of its online services. With this new action, we are driving faster internet-wide adoption of HTTPS and promoting better privacy standards for the entire browsing public."

(Disclaimer: I work on https://https.cio.gov, at GSA.)

Tough to say without knowing more about the stack. But in terms of first byte latency, some things you can look at:

* TLS False Start

* HTTP/2 + ALPN

* Optimizing TLS record size

Some 2013-era advice for nginx here: https://www.igvita.com/2013/12/16/optimizing-nginx-tls-time-...

And some other advice and links here: https://istlsfastyet.com/

Yes, the federal CIO is a presidential appointment.

Right, but if it's HTTPS, only the website can give you a virus. If it's HTTP, the website can give you a virus, plus the owner of any network device your requests traveled through on the way to and from the website. That's often a lot of owners.

It's just basic connection integrity -- without HTTPS, there's no guarantee the user is actually getting the content that the site meant to send, and vice versa. Those kind of attacks really do happen, and at scale (e.g. Verizon XUID, or China's Great Cannon).

If it's at all interesting, I laid out in detail, with examples, why I've been comfortable taking a very hard line on deprecating HTTP:

https://konklone.com/post/were-deprecating-http-and-its-goin...

Analytics makes websites better, and Piwik is not easy or cheap to use at scale. Sharing web traffic data with Google Analytics (especially with IPs anonymized) is a pretty small issue IMO, especially when the benefits are you get good data like what's on analytics.usa.gov.

(Disclosure: I work on analytics.usa.gov.)

It's open source. ;) https://github.com/18f/analytics.usa.gov#analyticsusagov

While it might assuage some kneejerk skepticism like this, I don't think they're obligated to omit that Chrome has mitigations in place when disclosing a vulnerability.

While this is plausible for the past, I think this info is outdated now. https://analytics.usa.gov has lots of data on this (and you can break it out by agency using the dropdown at the top). It also estimates that only 5% of data comes from federal networks.

(Disclaimer: I work on analytics.usa.gov.)

Or it's just P0 following their policy. Which is the only way P0 can maintain credibility and exert pressure on vendors to fix things. Especially after Google management just publicly overrode them regarding an Apple vulnerability a week or so ago.

It's both. 18F hosts the code and led the development, but there were major contributions from USDS (such as the visual design). And the program itself is owned and directed by the Digital Analytics Program, another team in the GSA. It was a team effort.

Wordpress did this by issuing Let's Encrypt certs on demand for every domain people CNAME their way.

> Overall, GSA is one of the best agencies when it comes to open source. It has definitely come a long way, but still a long way to go.

I think it's never been a better time to get approvals/clarifications/etc for open source at GSA. GSA's CIO posted a supportive comment on this issue here, w/r/t the White House's proposed source code policy (and 18F's comment on it), and reinforced that GSA has an "open source first" internal policy for the enterprise on the books:

https://github.com/WhiteHouse/source-code-policy/issues/73#i...

Of course, policies only give people the space to spend energy making the policy really mean something -- which I encourage you to do. Find me on 18F's GitHub or GSA email any time if you have ideas you want to talk about.

Sure, we have a lot of ATO/compliance stuff in the open:

https://pages.18f.gov/before-you-ship/

And there's a GitHub repo with an issue tracker that would make for better conversation capturing than HN:

https://github.com/18f/before-you-ship

Compliance: https://pages.18f.gov/before-you-ship/

Hiring: https://pages.18f.gov/joining-18f/

This is actually a great time to talk about this stuff, but maybe easier on email (firstname.lastname@gsa.gov) than HN. Drop me a line!

It's down for some internal IT reasons, but should be back up at some point soon (but not this weekend).

Yeah, I'm torn on it. It's clearly not the right information. But one of the benefits of an automated approach is that everyone's being treated equally, and people can't complain about unfair treatment.

In the case of the Senate, their current configuration prevents them from using HSTS or enforcing HTTPS, so the other columns will still show as lacking.

The world is a complicated place, and the US government is a highly decentralized organization. (And in the case of the executive and legislative branches, decentralized very much by design.)

Yes, the IPv6 is a White House (not GSA) mandate, like https://https.cio.gov. It doesn't apply to the legislative or judicial branches, and in that blog post, GSA is advertising the services it can offer other agencies to help them achieve IPv6 compliance.

Here's some rationale on why it's worth using HTTPS for everything, even the less sensitive things:

https://https.cio.gov/everything/

A lot of people focus on targeted surveillance of people visiting individual sites, but there are so many other threats and issues out there. Bulk modification of unencrypted traffic is a particularly nasty one, and has been seen in the wild, at scale, multiple times.

As a White House memorandum, that mandate only applies to the executive branch.

Though the GSA's HTTPS adoption dashboard does include legislative branch domains, including senate.gov:

https://pulse.cio.gov/https/domains/#q=legislative

We're federal government employees (and are allowed to use Slack).

I think this is a super important topic, that doesn't get a lot of discussion in the infosec community.