7 ms·

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.

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.