search

scipy-lectures / scientific-python-lectures

Tutorial material on the scientific Python ecosystem
https://lectures.scientific-python.org
Other
3.11k stars 1.19k forks source link

SEC: https://scipy-lectures.org #409

Closed westurner closed 5 years ago

westurner commented 5 years ago

When I access https://scipy-lectures.org (over HTTPS) I get a cert error.

GitHub Pages now supports HTTPS on custom domains (with https://letsencrypt.org/) https://github.blog/2018-05-01-github-pages-custom-domains-https/

https://help.github.com/articles/securing-your-github-pages-site-with-https/

https://help.github.com/articles/troubleshooting-custom-domains/#https-errors

pdebuyl commented 5 years ago

Thank you for notice @westurner

I disabled the custom domain and re-enabled it, which is recommended in the instructions of GitHub. Things should be ok in one hour, if not we'll have to look at our DNS settings. (The extended comment is also intended as a record for the other maintainers of the notes). Our internal links are relative, so I just hope this will not require other changes.

Regards,

Pierre

pdebuyl commented 5 years ago

The "unsafe" warning disappeared for me. I'll close the issue if this is confirmed by others.

P

westurner commented 5 years ago

https://www.ssllabs.com/ssltest/analyze.html?d=scipy-lectures.org

pdebuyl commented 5 years ago

The certificates are only valid for the www subdomain. The plain (no www) domain does not redirect properly. The tests for www.scipy-lectures.org are good: https://www.ssllabs.com/ssltest/analyze.html?d=www.scipy%2dlectures.org&ignoreMismatch=on&latest

@GaelVaroquaux are you managing the DNS record for scipy-lectures.org ? If so, can you enable a direct redirect of scipy-lectures.org to www.scipy-lectures.org? GitHub only allows a single domain name for the SSL certificates.

westurner commented 5 years ago

It should work with a naked (www.-less) domain (A records); but then you'd need a redirect for existing www. links.

GaelVaroquaux commented 5 years ago

OK, I'll try to work this out, but DNS is incomprehensible to me, and I must say that I am terrified to touch the configuration.

GaelVaroquaux commented 5 years ago

@pdebuyl : I don't know how to do a redirect.

Also: is to possible to redirect the www to the non www URL? I personally don't really like the "www". It makes the url longer for no good reason.

westurner commented 5 years ago

https://help.github.com/articles/about-supported-custom-domains/

https://help.github.com/articles/setting-up-an-apex-domain-and-www-subdomain/

Warning: If your domain has HTTPS enforcement enabled, GitHub Pages' servers will not automatically route redirects. You must configure www subdomain and root domain redirects with your domain registrar.

(Or e.g. CloudFlare, which does free HTTPS redirects)

https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/

https://gist.github.com/cvan/8630f847f579f90e0c014dc5199c337b

I looks like the option "Always use HTTPS" is not served as a page rule anymore. I found this option under the Crypto tab.

pdebuyl commented 5 years ago

@GaelVaroquaux for only the non-www version:

In the gandi dashboard: domains names -> DNS records.

  1. Have the lines:

@ | A | 1800 | 185.199.108.153 @ | A | 1800 | 185.199.109.153 @ | A | 1800 | 185.199.110.153 @ | A | 1800 | 185.199.111.153

This sets the "A" record (a main point of entry) to scipy-lectures.org

  1. Add a "redirection web" from the www address to the non-www address.

I actually don't care for the www, I find that for websites it can as well stay. Be aware though that google references the www version, as well as many existing links online. We wust pick only one of the two for sure, I tend to prefer stability/

pdebuyl commented 5 years ago

I usually manage the redirections in my apache/nginx config, I must admit.

GaelVaroquaux commented 5 years ago

How do I do step 2 (the redirection)?

⁣Sent from my phone. Please forgive typos and briefness.​

On Jan 28, 2019, 09:25, at 09:25, Pierre de Buyl notifications@github.com wrote:

@GaelVaroquaux for only the non-www version:

In the gandi dashboard: domains names -> DNS records.

  1. Have the lines:

@ | A | 1800 | 185.199.108.153 @ | A | 1800 | 185.199.109.153 @ | A | 1800 | 185.199.110.153 @ | A | 1800 | 185.199.111.153

This sets the "A" record (a main point of entry) to scipy-lectures.org

  1. Add a "redirection web" from the www address to the non-www address.

I actually don't care for the www, I find that for websites it can as well stay. Be aware though that google references the www version, as well as many existing links online. We wust pick only one of the two for sure, I tend to prefer stability/

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/scipy-lectures/scipy-lecture-notes/issues/409#issuecomment-458036292

pdebuyl commented 5 years ago

There is a tab in the settings, at the same level as "enregistrements dns", where you can add redirects.

GaelVaroquaux commented 5 years ago

There is a tab in the settings, at the same level as "enregistrements dns", where you can add redirects.

I am not sure what you are talking about. On the Ghandi interface, I have no "settings" tab, and nothing that looks like "enregistrements dns" (or the English version). The Ghandi interface allows me to add entries to the DNS records: "A" entries, "CNAME", and the like.

I've added a "CNAME", which after googling seems to be redirect in DNS (but honestly, I am clueless with DNS). I've deployed the DNS configuration.

Right now, we are getting a certificate failure in HTTPS. Hopefully it is because the DNS records have not propagated.

pdebuyl commented 5 years ago

DNS timeout is 3 hours for scipy-lectures.org, and GitHub delay for propagating certificates is estimated at 1 hour. We'll have to wait some time anyway :-)

The CNAME is an alias, not a redirect, so the failure will remain. Let's wait for the timeouts (at 14:30) before evaluating.

I sent you an email with a screenshot of the gandi panel to make sure we are on the same page.

GaelVaroquaux commented 5 years ago

OK, it seems that I had to change Gandi version and hence transfer the domain handling to new DNS servers to enable the redirection. I did that (I definitely feels like the sorcerer's apprentice). Now we need to wait for everything to propagate.

pdebuyl commented 5 years ago

The new interface allows dns setup "by record", I find it much easier. I am definitely not expert on DNS but we should be able to manage this :-)

Did you setup also the redirection?

GaelVaroquaux commented 5 years ago

I did setup up the redirect (call "forwarding" in the new interface). They told me that they needed to migrate the configuration to new servers for the redirect to work, and that it could take 24H. Let's see what happens.

westurner commented 5 years ago

AFAIU, this means that there is now an HTTP but not an HTTPS redirect?

On Monday, January 28, 2019, Gael Varoquaux notifications@github.com wrote:

I did setup up the redirect (call "forwarding" in the new interface). They told me that they needed to migrate the configuration to new servers for the redirect to work, and that it could take 24H. Let's see what happens.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/scipy-lectures/scipy-lecture-notes/issues/409#issuecomment-458104609, or mute the thread https://github.com/notifications/unsubscribe-auth/AADGy7og22S04CTDaZlmjHLJZlSCH13-ks5vHuYtgaJpZM4aT51U .

pdebuyl commented 5 years ago

Whenever the setup works correctly, we can add extra redirects via the dns provider. All http to https, for instance (i.e. for both www and non-www urls). Do we want to enforce all https?

westurner commented 5 years ago

All HTTPS is the least risk for this sensitive material.

Does your DNS provider do HTTPS redirects? It'd need to generate SSL certs for each domain with e.g. https://letsencrypt.org, just like GitHub and CloudFlare.

I've emailed GitHub about just handling www. HTTPS redirects hopefully by just optionally requesting the www. and Apex domain in the cert request (and the cert subjectAltNames). IDK if that's possible (wildcard domain certs now are) or when or whether it might be implemented.

On Monday, January 28, 2019, Pierre de Buyl notifications@github.com wrote:

Whenever the setup works correctly, we can add extra redirects via the dns provider. All http to https, for instance (i.e. for both www and non-www urls). Do we want to enforce all https?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/scipy-lectures/scipy-lecture-notes/issues/409#issuecomment-458125558, or mute the thread https://github.com/notifications/unsubscribe-auth/AADGyxfXVpeQ5arhV2wBxHHn4sjUYAu0ks5vHvcRgaJpZM4aT51U .

GaelVaroquaux commented 5 years ago

All HTTPS is the least risk for this sensitive material.

Except HTTPS is always broken due to certificates issues. I understand the logic behind all this, but right now the whole thing is just terribly fragile.

Does your DNS provider do HTTPS redirects?

I think so, but I understand little to all this.

It'd need to generate SSL certs for each domain with e.g. https://letsencrypt.org, just like GitHub and CloudFlare.

Following the instructions on Github pages, I've just deleted and recreated our CNAME instruction on Github. They mention that this can be necessary to trigger the update of the certificate.

I did it right now. Let's see if it solves the problem. I see two steps: first getting it to work for the non www address (which should be solved by my operation above, maybe in an hours). Second: getting the redirect to work. This should be fixed by my operation on the DNS provider. But, because apparently they need to migrate to a new DNS server, it might take longer, as long as 24H.

GaelVaroquaux commented 5 years ago

I did it right now. Let's see if it solves the problem. I see two steps: first getting it to work for the non www address (which should be solved by my operation above, maybe in an hours).

Update: https://scipy-lectures.org/ now works! Hopefully this is not a transitory status while some error that I've made is still propagating through the system.

GaelVaroquaux commented 5 years ago

Hum, looks like both work.

Can people confirm?

Once again, I hope that we have no surprise lingering in an unpropagated change. I understand nothing of this wizardry.

westurner commented 5 years ago

When HSTS is on, the HTTP server sends an extra header that causes the browser to make all future requests over HTTPS only

pdebuyl commented 5 years ago

The https://www.scipy-lectures.org to https://scipy-lectures.org redirect works now in one of my browsers. Maybe still a caching issue.

pdebuyl commented 5 years ago

Now both my browsers resolve all the links and go to the non www version.

http remains http and https remains https

To me, we can leave it so. @westurner you seem to push for "all https", but in the lecture notes the code seems pretty innocent (small snippets, and mostly copy-pasted). Am I being simplistic here?

westurner commented 5 years ago

Still getting connection reset from here. I'll check again in a few hours. Thanks for addressing this

On Monday, January 28, 2019, Pierre de Buyl notifications@github.com wrote:

The https://www.scipy-lectures.org to https://scipy-lectures.org redirect works now in one of my browsers. Maybe still a caching issue.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/scipy-lectures/scipy-lecture-notes/issues/409#issuecomment-458183060, or mute the thread https://github.com/notifications/unsubscribe-auth/AADGy0YoUn8YYoST0mJeGhlJeTQGFW8qks5vHxtrgaJpZM4aT51U .

GaelVaroquaux commented 5 years ago

To me, we can leave it so. @westurner you seem to push for "all https", but in the lecture notes the code seems pretty innocent (small snippets, and mostly copy-pasted). Am I being simplistic here?

I think that the issue is that HTTP leave the door open to man in the middle attack. For instance an ISP, or a government, injecting tracking code in webpages. This has been done in the past, so the question is a real one.

However, I'd rather wait for the dust to settle down on our HTTPS serving before enforcing it (I am a bit traumatized by DNS :D ).

GaelVaroquaux commented 5 years ago

OK, I'm closing this issue, and we can revisit later the idea of redirecting HTTP to HTTPS.