use HTTPS

[junosuarez]

• 18F has an HTTP-by-default policy: https://github.com/18F/api-standards#always-use-https
• Google has announced that they will be factoring HTTPS into their ranking facotrs http://googleonlinesecurity.blogspot.com/2014/08/https-as-ranking-signal_6.html
• See also this presentation on HTTPS Everywhere from Google/IO https://docs.google.com/presentation/d/15H8Sj-Zol1tcum0CSylhmXns5r7cvNFtzYrcwAzkTjM/present#slide=id.g12f3ee71d_10 (video: https://www.youtube.com/watch?v=cBhZ6S0PFCY)

The entire codeforamerica.org site - including and especially /api - should be served exclusively over HTTPS

[migurski]

Sorry, not anytime soon.

[andrewmaier]

Pardon my ignorance, but what all is required to make this happen?

[migurski]

You have to buy an SSL certificate and replace it each year, then modify your web server configuration to serve over SSL. Ideally you'd also update links and set up redirects to the new SSL-enabled locations. In our case, we'd additionally have to figure out what to do with external resources like fonts and styles hosted elsewhere—browsers can be picky about mixed content.

Overall, a surmountable hassle that we may eventually choose to do but not for now.

[konklone]

Please reconsider closing this -- SSL is important, not as hard to set up as all that, and a curve worth getting ahead of.

You have to buy an SSL certificate and replace it each year

You can obtain certs that last for multiple years, and for cheap. They do need to be bought and renewed, but in this way it's the same burden as a domain name.

then modify your web server configuration to serve over SSL.

With nginx, this is extremely easy. (More on that below.)

If you're using a CDN, some are more annoying or expensive than others. Akamai is terrible, CloudFront is okay. Cloudflare is a vigorously pro-SSL company, and so you can get extremely high quality SSL for $20/month (they're making it free in October).

Ideally you'd also update links and set up redirects to the new SSL-enabled locations.

The nginx redirect is straightforward, and updating links really should just mean making them relative, or protocol-relative (e.g. //assets.codeforamerica.org), which is good practice anyway. (edit: protocol-relative URLs are not good practice anymore.)

In our case, we'd additionally have to figure out what to do with external resources like fonts and styles hosted elsewhere—browsers can be picky about mixed content.

They definitely can, and protocol-relative URLs are the easiest way to make your site agnostic to the protocol it's served over. At this point, every major Internet service I've ever used (Chartbeat, Google Analytics, whatever) makes this a trivial change.

Overall, a surmountable hassle that we may eventually choose to do but not for now.

In my personal and professional experience, it's a much more surmountable hurdle than it may seem at first, and is worth prioritizing.

If it's any help, I've written a decent guide that covers 3 things: 1) generating a private key and cert request, 2) obtaining a free, 1-year cert from StartSSL, and 3) configuring nginx for SSL. Each of those are separate things, you can do any of them differently, so it may be useful for any of them.

In particular, I'm very confident at this point in my nginx configuration, which I've worked into my personal sites, and 18F's default server configuration for our future apps.

[konklone]

I hit Ctrl+Enter by accident, which apparently is a keyboard shortcut to post a comment. My remaining comment --

We have an all-SSL policy at 18F, not just for our APIs, but for everything we do. It's respectful to our visitors' privacy, acknowledges how difficult it can be to predict how intercepted traffic can be analyzed or changed, and gives us a few benefits (HTTPS referers in our analytics, allows our APIs and assets to be used on other HTTPS websites, and now a Google SEO boost). For our websites, using SPDY (and soon HTTP/2) gives a nice speed boost besides.

Once you do it a time or two, and you operationalize it, it becomes a very small hassle. The future of HTTP is encryption by default, and as a civic technology leader, Code for America should be in front of it.

[migurski]

Thanks for your notes Eric! I'm going to keep the ticket closed but it's super helpful to have these notes for future reference.

[gbinal]

Wow.

[adelevie]

I'd hate to see a civic technology leader, as @konklone phrased it, used as an example for other sites to not use SSL.

[migurski]

Sorry to disappoint!

The reasoning behind SSL is sound for sensitive data, but our website does not fall into that category.

[migurski]

Also, to be clear: I'm not disputing the importance of SSL, just its urgency. We'll get around to this at a future time.

[gbinal]

I was just surprised at the 'No thanks, why leave an active github issue open' part.

[rebeccawilliams]

@migurski, any way we can reopen this issue?

I tried to embed the fantastic civic issue finder today, but can't use it because of mixed content issues:

[adelevie]

👍, @rebeccawilliams.

Since @konklone wrote this, SSL with nginx has become even easier thanks to @vzvenyach's nginx-ssl script. As long as someone in your organization can open email from any of the following accounts, setting up SSL with nginx will literally take less than 15 minutes:

• The webmaster@, hostmaster@, postmaster@, admin@, or administrator@ addresses at either your domain or the sub-domain for which you are buying a certificate.
• One of the email addresses listed in the publicly-available whois record for your domain. (Note: this is only available with TLDs that publish email addresses in the public whois system.)

(from the sslmate faq)

$ whois codeforamerica.com
...
Admin Email: [email protected]
...

[konklone]

Code For America's servers use Apache, but the issue is fundamentally the same - make the .crt and .key using SSLMate, and then point Apache at them.

CourtListener is an example of a civic tech app that uses HTTPS on Apache, and they use this configuration to get an A SSL Labs grade. The only reason they don't get an A+ is because of the SHA-1 certificate -- and you won't run into that with SSLMate, which uses SHA-2.

[migurski]

We’ve been slowly getting up on SSL, starting with upstream dependencies like https://style.codeforamerica.org. I’ve left https://www.codeforamerica.org as the final domain to get an update.

FWIW, learned some interesting things along the way about incompatibilities between SSL and Host headers. I know it’s rhetorically important to present enabling SSL as quick switch to flip, but that’s not been my actual experience. SSL—it’s right there in the word “hassle”!

[migurski]

SSL is up on the main domain: https://www.codeforamerica.org/

I may need some help testing to make sure that it’s embeddable, @ondrae or @rebeccawilliams.

[rebeccawilliams]

Awesome! Awesome! I'll test today and let you know.

[rebeccawilliams]

Looks like there are still issues, see: https://codeforamerica.org/geeks/civicissues/widget?organization_name=Data.gov&labels=help%20wanted&number=12, @ondrae?

[migurski]

Looks okay with the www. added: https://www.codeforamerica.org/geeks/civicissues/widget?organization_name=Data.gov&labels=help%2520wanted&number=12

[rebeccawilliams]

Ah! The embed styling is off though:

I think the embed tool links need to be updated to https:// to fix.

[junosuarez]

👏 👏 👏 🎉 🎊 🍻

[konklone]

There are links to insrecure http:// images and stylesheets. Fortunately, style.codeforamerica.org has https:// enabled, so some updates to the links should fix it.

[ondrae]

I'm working on the https links in the civic issue finder.

[ondrae]

Got it. Try it out now.

[rebeccawilliams]

Embed works and is live: https://www.data.gov/developers/open-source

Thank you so much. In the words of @jden: 👏👏👏🎉🎊🍻

[migurski]

Yeah! 🍸 👌

[junosuarez]

Following up on this:

• is there any intention of redirecting http -> https? Ideally, this would be in place with HSTS headers enabled.
• There are still insecure resources on the page:
  

In transitioning to HTTPS-only resources, you can use Content Security Policy reporting to figure out which resources are being loaded without TLS by setting policy in Report-Only mode to only allow https and setting a report endpoint, eg Content-Security-Policy-Report-Only: default-src https:; report-uri: https://codeforamerica.org/csp-report-endpoint. See http://content-security-policy.com/ for more

[junosuarez]

From dev tools:

[konklone]

It looks like @jden has made some great progress in #1021 and #1022.

@jden, take a look at https://github.com/codeforamerica/codeforamerica.org/pull/912 -- I did a lot of this work there a couple months back, but it was unmerged and now has a conflict and needs to get re-synced with master. Feel free to either resolve the conflict, or borrow it for inspiration.