Use HTTPS by default

[csoghoian]

Any new federal website should be using HTTPS by default. In 2014, there just isn't a good reason to not do so.

I realize that you are using github pages for playbook.cio.gov, and that github pages does not let you use a custom domain name with HTTPS (see https://konklone.com/post/github-pages-now-supports-https-so-use-it for more info). Until github fixes this, the right solution is for you to host your website elsewhere. Perhaps you could use Amazon Cloudfront+S3, which supports HTTPS for free, and allows custom domains.

HTTPS by default is the right thing to do, and you should be setting a good example for other agencies. Plus, it will help your Google pagerank (see: http://googleonlinesecurity.blogspot.com/2014/08/https-as-ranking-signal_6.html)

[konklone]

:+1:

Completely agree with @csoghoian that all new federal websites should use HTTPS by default. There are lots of good reasons for it, and it's why 18F is an all-SSL shop.

One interim way to address this without moving away from GitHub Pages is by putting Cloudflare in front of the domain, but you can only make that work by doing it the "wrong way" with "Flexible SSL", which allows the connection between Cloudflare and GitHub to run unencrypted. This is what MayDay.us is doing, and it's not a great idea. If you do it the right way and turn on "Strict SSL", you'll get an error (I'm currently getting this error on a separate domain of mine), because GitHub is not configured to handle this situation.

This is because GitHub does not officially support HTTPS for Pages. Unfortunately, until they do, GitHub Pages is just not a great hosting platform for production websites with custom domains. There's been no movement from GitHub's end since April, so I'm looking to migrate my own away from GitHub until things change.

[cew821]

Do you think the cloudflare step is worth taking or does that not really address the problem given the Flexible SSL setting?

[benbalter]

GitHub Pages is just not a great hosting platform for production websites with custom domains

SSL is great, and it's no secret that there are some very vocal SSL zealots out there, but for me, the question is given the constraints we're currently faced with, is it preferable to not be SSL or to not be collaborative (factoring in the necessary administrative overhead on both sides).

Cloudflare has not federal terms AFAIK, requiring a human to deploy to S3 is a big step away from merge a pull request and your change is live, not to mention, procurement, legal, security, etc. review for the added complexity.

SSL is great, but lightweight solutions that actually make it out the door are even better.

[jvoorhis]

I would advise considering the context. Supporting SSL builds trust with users, and Google now uses SSL as a ranking signal. The current mismatched certificate warning does not inspire confidence.

Deploying to S3 need not be much more difficult than deploying to GH pages. I do this using a single command with middleman and the s3_sync plugin, for example. You can also use Jenkins or a similar service to glue Github and S3 together, eliminating the manual step.

[konklone]

Do you think the cloudflare step is worth taking or does that not really address the problem given the Flexible SSL setting?

If it was me, I'd use Flexible SSL and be fine with it here, since the Playbook is a passive site. And that way, you get to keep the automatic deployment properties of GHP.

(With MayDay.us, they actually accept donations through their GHP site, which is why I think their use of Flexible SSL was a poor choice.)

requiring a human to deploy to S3 is a big step away from merge a pull request and your change is live, not to mention, procurement, legal, security, etc. review for the added complexity.

I agree, the instant deploy is hugely valuable. Ideally, Cloudflare can be made to work, which preserves that.

Alternately, Amazon CloudFront, but it costs quite a bit of money for SSL support -- unless you use SNI, which the White House network blocks for inexplicable reasons. I can also imagine using a post-push hook to automate a deploy to S3 -- setting up a little Heroku service to do just that would be a fun afternoon project.

SSL is great, but lightweight solutions that actually make it out the door are even better.

They're both needed these days, and we can find or make solutions that don't force you to choose.

[jvoorhis]

They're both needed these days, but we can find or make solutions that don't force you to choose.

Exactly. It's a false dilemma, and we shouldn't have to sacrifice either benefit.

[seanherron]

Echoing @konklone's note, I think CloudFlare Flexible SSL is an option you should strongly consider here. We discovered with openFDA that many corporate security appliances (including the White House) block sites using SNI. Unless you deploy this on a server you control, getting SSL through a CDN will be fairly expensive ($600/month with Amazon CloudFront). CloudFlare supports SSL without using SNI at a fairly low price point (and soon free).

[csoghoian]

I'm one of the "SSL zealots" that @benbalter references in his comment above.

The websites for the CIA, The National Geospatial-Intelligence Agency, USPS Inspector General and HealthCare.gov all use HTTPS by default. These agencies are doing the right thing. Many others are not. U.S. Digital Services should be helping to move agencies in the right direction, and that includes making sure that its own website is using HTTPS by default.

That the U.S. Digital Services team is using GitHub pages to host a new, high-profile website is a serious feather in the cap for GitHub. After all, U.S. Digital Services is supposed to be helping others in the Federal government figure out how to do tech stuff the right way. However, until GitHub permits HTTPS for custom domains, the company should not be rewarded with the free PR and glory that comes along with U.S. Digital Services' endorsement.

[akuckartz]

I vote for resolving this issue as suggested by @csoghoian

[grittygrease]

CloudFlare also offers a mode called "Full SSL" which does provide encryption between CloudFlare and Github. This is strongly recommended over "Flexible SSL" and works great with Github pages that have custom domains.

Furthermore, CloudFlare's CNAME flattening makes Github pages with custom domains load significantly faster: http://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root

[seanherron]

@grittygrease Wow, that's a great point and something I completely overlooked. If the origin is set to https://whitehouse.github.io/playbook with the https://playbook.cio.gov URL being sent to CloudFlare then you can encrypt everything without issue.

[konklone]

Yes, that would work too. Cloudflare's "Full SSL", when Strict mode is not enabled, provides encryption between CF and GitHub, but doesn't verify the cert.

For an API or a donation-accepting site this would not be good enough for me, but for a static site like the Playbook, Flexible or Full (with Strict disabled) is just fine.

[NoahKunin]

I just want to briefly comment there are actual two issues here:

• Should the Playbook itself include HTTPS default as a checklist item?

We went back on forth on how tactical the Playbook should get. HTTPS by default was in fact in there for a period of time. Ultimately the consensus is the Playbook should first operate on a high-level and more tactical guides to accomplish the outcomes of the checklists should come later. As we build the Playbook, I can imagine direct links from the sections on security and privacy to a tactical implementation guide which would include best practices around TLS generally. Even though I had previously supported putting HTTPS into the Playbook, I'm happy with the level of abstraction we ended up with and would recommend we put that into subsequent implementation guidance.

• Should playbook.cio.gov run as HTTPS by default?

The latest news that Google is using HTTPS in its ranking is the biggest thing on supporting a business case for HTTPS by default, even where the privacy or security concerns are light. In addition, even though the current use case of a site might not directly call for HTTPS, setting it up when moving to production means you have one less thing to worry about when later deploying features that require HTTPS.

There's also a consideration for a unity of user experience and their expectations. Even if it runs on separate infrastructure on the playbook subdomain, cio.gov runs as HTTPS by default. Consistency is certainly needed here - cloud.cio.gov(https://cloud.cio.gov/) supports HTTPS but can run as HTTP.

All of these sites should have a consistent policy re HTTPS .

[PaulSD]

Fixed.

[cew821]

Thanks all for the discussion and @PaulSD for the implementation.

[konklone]

:+1: Thanks for making this happen!

[cben]

FYI, even if Cloudflare allowed Full Strict, there would remain an insecure link. Github support has explained:

While HTTPS requests may appear to work, our CDN provider is adding and removing the encryption at their end, and then the request is transmitted over the open internet from our CDN provider to our GitHub Pages infrastructure, creating the appearance of trustability.

-- full text in comment on Eric's post

As long as that is true, there is no way to secure Github Pages. Doesn't change your reasoning for a static site, but worth knowing.

[konklone]

As long as that is true, there is no way to secure Github Pages. Doesn't change your reasoning for a static site, but worth knowing.

Correct on both counts. FWIW, the site doesn't use CloudFlare, but rather an in-house proxy, configured by @PaulSD. That doesn't solve the problem of the link between Fast.ly and GitHub, which is something out of our control. I think the team here's done the best they can under the circumstances, and aren't running a website that's likely to put people at risk (unlike the MayOne.us example I linked above, the discussion of which has sadly been taken offline).