New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use HTTPS by default #22

Closed
csoghoian opened this Issue Aug 12, 2014 · 18 comments

Comments

Projects
None yet
@csoghoian

csoghoian commented Aug 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@konklone

konklone Aug 12, 2014

👍

playbook

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.

konklone commented Aug 12, 2014

👍

playbook

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

This comment has been minimized.

Show comment
Hide comment
@cew821

cew821 Aug 12, 2014

Contributor

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

Contributor

cew821 commented Aug 12, 2014

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

@benbalter

This comment has been minimized.

Show comment
Hide comment
@benbalter

benbalter Aug 12, 2014

Contributor

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.

Contributor

benbalter commented Aug 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jvoorhis

jvoorhis Aug 12, 2014

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.

jvoorhis commented Aug 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@konklone

konklone Aug 12, 2014

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.

konklone commented Aug 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jvoorhis

jvoorhis Aug 12, 2014

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.

jvoorhis commented Aug 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@seanherron

seanherron Aug 12, 2014

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

seanherron commented Aug 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@csoghoian

csoghoian Aug 12, 2014

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.

csoghoian commented Aug 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@akuckartz

akuckartz Aug 12, 2014

I vote for resolving this issue as suggested by @csoghoian

akuckartz commented Aug 12, 2014

I vote for resolving this issue as suggested by @csoghoian

@grittygrease

This comment has been minimized.

Show comment
Hide comment
@grittygrease

grittygrease Aug 13, 2014

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

grittygrease commented Aug 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@seanherron

seanherron Aug 13, 2014

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

seanherron commented Aug 13, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@konklone

konklone Aug 13, 2014

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.

cloudflare-ssl

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.

konklone commented Aug 13, 2014

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.

cloudflare-ssl

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

This comment has been minimized.

Show comment
Hide comment
@NoahKunin

NoahKunin Aug 13, 2014

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 .

NoahKunin commented Aug 13, 2014

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 .

@cew821 cew821 added the technical label Aug 13, 2014

@compleatang compleatang referenced this issue Aug 22, 2014

Closed

ssl #13

@PaulSD

This comment has been minimized.

Show comment
Hide comment
@PaulSD

PaulSD commented Aug 23, 2014

Fixed.

@cew821

This comment has been minimized.

Show comment
Hide comment
@cew821

cew821 Aug 23, 2014

Contributor

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

Contributor

cew821 commented Aug 23, 2014

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

@cew821 cew821 closed this Aug 23, 2014

@konklone

This comment has been minimized.

Show comment
Hide comment
@konklone

konklone Aug 23, 2014

👍 Thanks for making this happen!

konklone commented Aug 23, 2014

👍 Thanks for making this happen!

@cben

This comment has been minimized.

Show comment
Hide comment
@cben

cben Jul 21, 2015

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.

cben commented Jul 21, 2015

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

This comment has been minimized.

Show comment
Hide comment
@konklone

konklone Jul 21, 2015

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

konklone commented Jul 21, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment