Open strugee opened 7 years ago
Okay, here's what this needs from Evan:
brett.ns.cloudflare.com
and miki.ns.cloudflare.com
I've set up Cloudflare in advance so it'll just roll over with no downtime.
I probably should've cc'd @evanp :D
Whoops.
Opportunistic encryption will kick in immediately, which is already a win, but in order to enable full HTTPS we need to wait a bit for TLS certificates to roll out. So I'll need to manually flip on the HTTP -> HTTPS redirection.
FWIW I've also whitelisted access from Tor, which is something Cloudflare is known to handle problematically.
@strugee
Could this bug be fixed by using certificates from https://letsencrypt.org ? You might already know that this service was graciously provided by the EFF (Electronic Frontier Foundation).
@yeehi I am a big fan of Let's Encrypt. Big fan (see for example pump-io/pump.io#1259). However the issue here is that the website is hosted through GitHub Pages so none of us control the origin server.
Also, FWIW, there are other organizations besides the EFF involved in Let's Encrypt! See this list :)
See also isaacs/github#156 (but do NOT leave a +1 comment there; that thread has far too many of those anyway)
This is pretty easy.
How to serve a custom HTTPS domain on GitHub Pages with CloudFlare: FREE, secure and performant by default: https://gist.github.com/cvan/8630f847f579f90e0c014dc5199c337b
OK, I tried to do this, but I've got a problem getting into the account on 101domain that has the pump.io domain on it. It's registered to evan@status.net, and I sold the status.net domain last year!
They're sending me some confirmation info, but until then I can just copy over the A & MX records to the Rackspace DNS manager, where pump.io is being handled right now. Sound good?
@strugee - There are many in the Free software community who object to CloudFlare for several reasons. (It could be considered a sort of proxy for the internet/Google, also there are censorship concerns behind using it.
If something like CloudFlare must be used for some reason, a couple of alternatives to consider would be PerimeterX:
@yegortimoshenko heh, I'm aware, thanks to isaacs/github#156 :)
Right now we need @evanp to recover control of the pump.io domain.
Or, I guess he can still update A records? I'll ping him on IRC soon.
https://pump.io does listen on HTTPS port, but sends wrong certificate:
$ curl https://pump.io
curl: (60) SSL: no alternative certificate subject name matches target host name 'pump.io'
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
Here's the certificate that GitHub tries to use:
* Server certificate:
* subject: C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=*.github.com
* start date: Mar 20 00:00:00 2017 GMT
* expire date: Apr 7 12:00:00 2020 GMT
* subjectAltName does not match pump.io
I think the solution is to follow step 4 here: https://help.github.com/articles/setting-up-an-apex-domain/#configuring-a-records-with-your-dns-provider
- Add your custom domain to your GitHub Pages site. If you're updating the IP address of an existing A record, first remove and then re-add your custom domain to the repository you’re using to publish your Pages site to trigger the process of enabling HTTPS. For more information, see "Adding or removing a custom domain for your GitHub Pages site."
It means that it should be enough to just remove CNAME
file and then add it back. @strugee maybe that's a good plan, provided that you have push access?
It would be nice if we could throw Cloudflare in front of http://pump.io, to take advantage of their free HTTPS thing. This will boost our SEO ranking and also prevent passive attacks, which will be a good start.
Obviously it'd be better to do HTTPS properly, but my feeling is that this is better than nothing. The one downside is that this potentially gives people a false sense of security but a) it seems like if someone did do something (unlikely given the cost/value ratio here) the impact would be minimal anyway, plus b) people do a terrible job of looking at security indicators anyway tbh.