24 ms·

Hello, very interested in this, thanks for making this event. Maybe I’ll join tomorrow. This is one of the few websites that don’t force you to use https even

Hello, very interested in this, thanks for making this event. Maybe I’ll join tomorrow. This is one of the few websites that don’t force you to use https even though it does have it! Impressive. In the spirit of keeping things open and without a user account, I’d recommend setting up some jitsi [0] conference rooms that don’t require an account. [0] https://jitsi.org/ https://jitsi.org/

cookingoils 5y ago
Thanks for that suggestion. We haven't used Jitsi but will look into it. Hope to see you at the freewrite.
chrismorgan 5y ago
> This is one of the few websites that don’t force you to use https even though it does have it! That’s bad, not good. Cleartext HTTP is a nice idea for an ideal world, but that’s not the world we are in: it’s demonstrably a vector for abuse, both passive and active. Save for a very few specific use cases (captive portal detector being the main one), it is irresponsible to support cleartext HTTP for any purpose but redirecting to HTTPS, preferably with a Strict-Transport-Security header so that that particular user agent skips straight to HTTPS forever after.
- tasogare 5y ago
  We're speaking about static websites, there is no password to steal and MITM attacks again such content is very highly unlikely.
  - boberoni 5y ago
    It is true that this website has no password to steal, but a MITM attack could still be impactful. For example, a MITM attack could inject a <script> tag to run arbitrary client-side code. Any content that is served over HTTP has a risk of being swapped out by a MITM, which is why most browsers are nudging users to only visit HTTPS websites. With that said, implementing security is a trade-off between your time and risk tolerance.
  - chrismorgan 5y ago
    A variety of ISPs in different countries, including some of the biggest ones in the USA and India, have been performing MITM attacks on HTTP traffic for many years, injecting their own stuff, sometimes to notify you of service-related matters (which is a terrible way of delivering such notifications, especially when it breaks various pages for various reasons), but I’m pretty sure I’ve heard of at least one case of them injecting ads and other potentially malicious stuff too. ISPs as a class have proven themselves untrustworthy, time and time again. Doing anything in cleartext is just asking for them to mangle it. And that’s just the active. The passive is pervasive too, and is an attack (RFC 7258). And so I use the term “irresponsible” of anyone running any web service except for a very few specific purposes over cleartext HTTP. There are reasons why we’ve shifted from cleartext to TLS for everything, not just for things conveying sensitive data.
    - goblin89 5y ago
      Not to argue against HTTPS, but it is not foolproof in case of a MITM on ISP level. I’m willing to be corrected here, but even if you (as a developer) use HTTPS, unless you are big enough that major browsers pin your certificates, initial connections still use HTTP—so a MITM can replace everything anyway, including presumably any HSTS headers you set; and if you (as a user) are conscious of that and use a private VPN that you trust, then serving a static website like the OP over HTTP shouldn’t be as much of an issue. I wonder if more malicious code is served from questionable ads on HTTPS sites than from ISP MITM injections into HTTP sites.
      - chrismorgan 5y ago
        Such an MITM-powered phishing attack is certainly possible, but in practice it’s not quite such a problem as it seems at first: ⓐ With a suitable HSTS and max-age header, it’s roughly only the first time you access the site at all that you’ll go via HTTP; ⓑ Anyone can submit their site to the HSTS Preload list <https://hstspreload.org https://hstspreload.org>, which solves the problem completely for a particular site (including subdomains); ⓒ It only applies to people typing in the URL manually: if your users come from a link from another site, that link should be HTTPS. This final point is really the key to it all, and the place where I wish browsers would hurry up: they should be shifting to interpreting URLs typed into the address bar with no scheme as https:, not http:. There will certainly be some rough edges that need to be caught with it, and you might want to set IP addresses and a small number of names to default to HTTP, but even without that, Firefox’s HTTPS-Only Mode has all the required ingredients: if I type “neverssl.com” into my address bar, it pops up the about:httpsonlyerror page, “HTTPS-Only Mode Alert / Secure Site Not Available” with explanatory text and buttons “Continue to HTTP Site” and “Go Back”. They could do something like that specifically for typed URLs. (You might think “just downgrade automatically”, but that’s an attack vector—they can just block port 443—where requiring manual user intervention with a mildly scary warning mitigates it somewhat.) The default really should be HTTPS by now. A little while after browsers all finally flip that specific thing over, I think we could collectively shut down port 80 for good, because no clients will ever try it any more.

cookingoils 5y ago

Thanks for that suggestion. We haven't used Jitsi but will look into it. Hope to see you at the freewrite.

chrismorgan 5y ago

> This is one of the few websites that don’t force you to use https even though it does have it! That’s bad, not good. Cleartext HTTP is a nice idea for an ideal world, but that’s not the world we are in: it’s demonstrably a vector for abuse, both passive and active. Save for a very few specific use cases (captive portal detector being the main one), it is irresponsible to support cleartext HTTP for any purpose but redirecting to HTTPS, preferably with a Strict-Transport-Security header so that that particular user agent skips straight to HTTPS forever after.

tasogare 5y ago
We're speaking about static websites, there is no password to steal and MITM attacks again such content is very highly unlikely.
- boberoni 5y ago
  It is true that this website has no password to steal, but a MITM attack could still be impactful. For example, a MITM attack could inject a <script> tag to run arbitrary client-side code. Any content that is served over HTTP has a risk of being swapped out by a MITM, which is why most browsers are nudging users to only visit HTTPS websites. With that said, implementing security is a trade-off between your time and risk tolerance.
- chrismorgan 5y ago
  A variety of ISPs in different countries, including some of the biggest ones in the USA and India, have been performing MITM attacks on HTTP traffic for many years, injecting their own stuff, sometimes to notify you of service-related matters (which is a terrible way of delivering such notifications, especially when it breaks various pages for various reasons), but I’m pretty sure I’ve heard of at least one case of them injecting ads and other potentially malicious stuff too. ISPs as a class have proven themselves untrustworthy, time and time again. Doing anything in cleartext is just asking for them to mangle it. And that’s just the active. The passive is pervasive too, and is an attack (RFC 7258). And so I use the term “irresponsible” of anyone running any web service except for a very few specific purposes over cleartext HTTP. There are reasons why we’ve shifted from cleartext to TLS for everything, not just for things conveying sensitive data.
  - goblin89 5y ago
    Not to argue against HTTPS, but it is not foolproof in case of a MITM on ISP level. I’m willing to be corrected here, but even if you (as a developer) use HTTPS, unless you are big enough that major browsers pin your certificates, initial connections still use HTTP—so a MITM can replace everything anyway, including presumably any HSTS headers you set; and if you (as a user) are conscious of that and use a private VPN that you trust, then serving a static website like the OP over HTTP shouldn’t be as much of an issue. I wonder if more malicious code is served from questionable ads on HTTPS sites than from ISP MITM injections into HTTP sites.
    - chrismorgan 5y ago
      Such an MITM-powered phishing attack is certainly possible, but in practice it’s not quite such a problem as it seems at first: ⓐ With a suitable HSTS and max-age header, it’s roughly only the first time you access the site at all that you’ll go via HTTP; ⓑ Anyone can submit their site to the HSTS Preload list <https://hstspreload.org https://hstspreload.org>, which solves the problem completely for a particular site (including subdomains); ⓒ It only applies to people typing in the URL manually: if your users come from a link from another site, that link should be HTTPS. This final point is really the key to it all, and the place where I wish browsers would hurry up: they should be shifting to interpreting URLs typed into the address bar with no scheme as https:, not http:. There will certainly be some rough edges that need to be caught with it, and you might want to set IP addresses and a small number of names to default to HTTP, but even without that, Firefox’s HTTPS-Only Mode has all the required ingredients: if I type “neverssl.com” into my address bar, it pops up the about:httpsonlyerror page, “HTTPS-Only Mode Alert / Secure Site Not Available” with explanatory text and buttons “Continue to HTTP Site” and “Go Back”. They could do something like that specifically for typed URLs. (You might think “just downgrade automatically”, but that’s an attack vector—they can just block port 443—where requiring manual user intervention with a mildly scary warning mitigates it somewhat.) The default really should be HTTPS by now. A little while after browsers all finally flip that specific thing over, I think we could collectively shut down port 80 for good, because no clients will ever try it any more.