search

openzipkin / openzipkin.github.io

content for https://zipkin.io
https://zipkin.io
Apache License 2.0
39 stars 64 forks source link

Support HTTPS #61

Closed shakuzen closed 6 years ago

shakuzen commented 7 years ago

Currently, zipkin.io does not support HTTPS and GitHub Pages don't appear to offer out-of-the-box support for HTTPS with custom domains. However, there are some articles out there of how you can get it to work, nonetheless. If we can achieve this with no cost except the one-time investment of time setting it up, I think it is worth it to make the move to HTTPS. What does everyone else think?

codefromthecrypt commented 7 years ago

@abesto any concerns?

abesto commented 7 years ago

I've used CloudFlare previously, didn't have any issues. Sounds sensible to me, with the minor note that I'm not sure what we'd gain - zipkin.io serves static content without any sensitive information being sent by either the client or the server. Still, good to have HTTPS just on principle.

basvanbeek commented 7 years ago

I'm only ok with this if it means CloudFlare can reverse proxy to a secured link of the site at openzipkin.github.io. If it means the transport between CloudFlare and Github is regular unsecured HTTP I think we are giving the wrong signal.

abesto commented 7 years ago

@basvanbeek That's a good point. There's no CloudFlare - GitHub secure link AFAICT. Thinking about signal to the user: since all the content is publicly available in the GitHub repo, I'm not exactly sure what the signal to the user even is.

basvanbeek commented 7 years ago

As a consumer I would like to be able to assume a link to be secure end to end when seeing HTTPS. That's why I consider HTTPS proxying like CloudFlare allows harmful.

Unfortunately due to SEO this is becoming more prevalent as HTTPS sites show higher up in searches.

I'd favor "true" HTTPS and if Github Pages can't deliver this for custom domains I'd rather migrate to a different host if we truly want HTTPS.

abesto commented 7 years ago

As discussed in github.com/isaacs/github/issues/156 (not linked to avoid spamming that issue) and https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/, it's now possible to use CloudFlare to terminate the HTTPS connection to zipkin.io, and configure CloudFlare to talk to openzipkin.github.io over HTTPS (*.github.io subdomains do support HTTPS). It's my understanding that this solves all our requirements - namely, end-to-end HTTPS. @basvanbeek agree?

basvanbeek commented 7 years ago

Yes that would be perfectly fine with me.

abesto commented 7 years ago

I've set up a test configuration under my personal CloudFlare account, currently waiting for the universal SSL cert to roll out (hopefully we don't actually need to redirect the nameserver for that to happen).

In the meanwhile, I've just learned: unless we pay monies, only browsers supporting SNI (https://en.wikipedia.org/wiki/Server_Name_Indication) will be able to access the site via HTTPS. Personally I think today this is fine, but want to allow anyone to veto.

devinsba commented 7 years ago

According to caniuse.com, 97% of internet users have SNI supporting browsers, and devs are generally skewed toward the latest and greatest anyway. I personally think it should be fine.

SOURCE: http://caniuse.com/#feat=sni

abesto commented 6 years ago

And done. http://zipkin.io now redirects to https://zipkin.io, which is served via CloudFlare. Thanks for the input, everyone!

codefromthecrypt commented 6 years ago

Thank you, lord of tenacity

On 26 Nov 2017 18:25, "Zoltán Nagy" notifications@github.com wrote:

And done. http://zipkin.io now redirects to https://zipkin.io, which is served via CloudFlare. Thanks for the input, everyone!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/openzipkin/openzipkin.github.io/issues/61#issuecomment-346997943, or mute the thread https://github.com/notifications/unsubscribe-auth/AAD618RX_SZxHmC5nTwvcu14XmcgLRpCks5s6TyTgaJpZM4KeHET .