Require HTTPS for contentmine.org

[ghost]

It would be great for contentmine.org to receive an "A" from SSL Labs: https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide .

Currently, it does not get a grade, due to a certificate name mismatch: https://www.ssllabs.com/ssltest/analyze.html?d=contentmine.org

Also good would be to use HSTS to defend against downgrade attacks.

[tarrow]

This could be nice; we could ask the cottage labs team about this. They're currently (very kindly) hosting our site's content. We've been planning a new wordpress site that we'll host somewhere else when it's ready to go (and thus can actually have ssl properly setup by us). This may or may not be really soon.

On Tue, May 16, 2017 at 7:05 PM, modem_down notifications@github.com wrote:

It would be great for contentmine.org to receive an "A" from SSL Labs: https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide .

Currently, it does not even get a grade, due to a certificate name mismatch:

https://www.ssllabs.com/ssltest/analyze.html?d=contentmine.org

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ContentMine/contentmine.org/issues/7, or mute the thread https://github.com/notifications/unsubscribe-auth/AHA0228vGJcjjjrP0r9_FbIyX7-bGGxLks5r6eVYgaJpZM4Nc321 .

[markmacgillivray]

It is not hard to add https to any site, including the contentmine site. However, whilst "https everywhere" is a fashionable thing at the moment and generally a good idea, on a site that provides absolutely no interactive features to the user and does nothing but serve static content, https does nothing but add additional load to both the server and the client. There are some reasons to use https even on static content, but unless the contentmine site has any such requirement, what would be the benefit of adding https to it?

[ghost]

@markmacgillivray wrote:

It is not hard to add https to any site, including the contentmine site.

Depends on the host. Some hosts charge a premium to enable HTTPS (Heroku used to do this). Some hosts don't support HTTPS at all (fortunately, this is increasingly rare), or don't support it for custom domains.

If you are from CottageLabs and you are able to add HTTPS to contentmine.org, that would be great! :)

"https everywhere" is [...] generally a good idea

:)

on a site that provides absolutely no interactive features to the user and does nothing but serve static content, https does nothing

I differ on this :) Static content can be (a) snooped, and (b) tampered with. HTTPS provides a measure of protection against both risks. That protection is good for everyone, but is especially important for website visitors in less tolerant jurisdictions than the UK. It is critically important for visitors using Tor, as it reduces the risk of injection-based de-anonymisation attacks.

You may find this infographic of interest.

but add additional load to both the server and the client.

Not significantly, AFAIK (except in the rare cases where HTTPS is exploited as a (D)DoS vector). See:

• https://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose/548042#548042
• https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
• https://istlsfastyet.com/

[markmacgillivray]

I'd suggest not using a web host at all - use a cloud VM provider, such as Digital Ocean (or any other provider you trust where you can ensure your VM is in an acceptable legal jurisdiction), then you can do whatever you want. For https certs, use letsencrypt/certbot.

This relates to your issue #9 and #8 as well - as has already been mentioned there, wordpress is a bad choice, as is any web host where you don't just have a VM that you have full control over, and install what you need onto that. By the way, the contentmine project already did have wordpress, already did move away from it for these reasons, and already did have a static site generator (and actually still is currently generated from one, although nobody seems to update it any more).

Static content can be snooped and tampered with, yes, but only if the static content includes a way to enable xss (any js-enabled buttons that trigger external actions, etc) or if it is viewed via a connection which can already be tampered with (e.g. if I can make you accept the terms of my internet service, I can also make you accept my server as an https cert intermediary, and MITM your https connection too, without you knowing (after the first acceptance of my service as a cert authority, which I can include in the seemingly harmless sign-up method). As for visitors using Tor or otherwise wishing to avoid de-anonymisation, I'd recommend not encouraging users to expect to be able to view any website without considering their own situation in the first place. If viewing a site that provides only static content of a non-contentious nature is still likely to lead to a user being de-anonymsied and worse things happening to them, but that user is not proficient enough in understanding their actions, then they are likely to already be in a much worse situation for which https would be nothing more than a false sense of security.

I'm not against https - I am for it - but I am against doing it just because people may then think they are safe, in a context where their security is either not really an issue or is likely to have already been compromised in other ways, beyond the scope of what can be solved by https. I think giving a false sense of security is worse than being explicitly insecure.

For the new site, whatever happens, something like a VM on digital ocean using a static site generator and certbot/letsencrypt for https would be the best approach (and is basically what is currently already being run at CL).

[ghost]

@markmacgillivray wrote:

For https certs, use letsencrypt/certbot.

Again, depends on the web host. If the host provides good letsencrypt integration, great. If not, but they provide a good alternative (there are many), then that's great too :)

Static content can be snooped and tampered with, yes, but only if the static content includes a way to enable xss (any js-enabled buttons that trigger external actions, etc) or if it is viewed via a connection which can already be tampered with (e.g. if I can make you accept the terms of my internet service, I can also make you accept my server as an https cert intermediary, and MITM your https connection too, without you knowing (after the first acceptance of my service as a cert authority, which I can include in the seemingly harmless sign-up method).

(My emphasis.) Again, I differ. Snooping does not require a way to enable XSS, nor does it require tampering with (i.e. compromising the integrity of) the traffic. See https://www.channel4.com/news/spy-cable-revealed-how-telecoms-firm-worked-with-gchq .

Tampering obviously does require tampering ;) But compared to tampering with HTTP, tampering with HTTPS-protected data imposes an increased cost and risk of failure on the attacker. They must either perform a downgrade attack (which can be blocked by HSTS), or require the user to install a non-default certificate (which can be refused by the user), or exploit an HTTPS vulnerability (which will hopefully be patched, so will not work indefinitely), or compromise a certificate authority (which is highly risky), or exploit the user's endpoint (which requires additional time and expertise), etc.

As for visitors using Tor or otherwise wishing to avoid de-anonymisation, I'd recommend not encouraging users to expect to be able to view any website without considering their own situation in the first place.

That's a straw man ;) (And I agree, no-one should encourage users to do any such thing!)

If viewing a site that provides only static content of a non-contentious nature is still likely to lead to a user being de-anonymsied and worse things happening to them, but that user is not proficient enough in understanding their actions, then they are likely to already be in a much worse situation for which https would be nothing more than a false sense of security.

They might be; they might not be. And what of visitors who are at risk but who are proficient? On the whole, it is up to the visitor to assess the visitor's threat model, not up to the site provider.

What is up to the website provider is to help the visitor to visit the site with the increased protection afforded by HTTPS, as the visitor cannot build an HTTPS connection to the website otherwise. Put differently, the only way for a visitor to be empowered to use HTTPS as part of their defensive strategy is for the website to offer it.

I'm not against https - I am for it - but I am against doing it just because people may then think they are safe, in a context where their security is either not really an issue or is likely to have already been compromised in other ways, beyond the scope of what can be solved by https. I think giving a false sense of security is worse than being explicitly insecure.

I agree that a false sense of security is dangerous. I disagree that the solution is to not enable HTTPS.

To counter false senses of security, Tor provides warnings, and Front Line Defenders provide trainings. Some of these warnings and trainings depend upon websites offering HTTPS :)