2 ms·

I don't disagree with what you've said, but why allow the risk to exist at all when something like Let's Encrypt protects against these sorts of attacks (better

I don't disagree with what you've said, but why allow the risk to exist at all when something like Let's Encrypt protects against these sorts of attacks (better than it used to, with TLS 1.2 and TLS 1.3 fixing the downgrade attacks present in older TLS/SSL implementations), and is trivial to set up? Sites hosted on HTTP, rather than HTTPS are doing a disservice to their visitors by putting their visitors at risk, needlessly so - the only reasons for a publisher to not enable HTTPS are laziness and ignorance, which are not virtues. Sure, the allegorical 12 year old nephew doesn't have zero days to burn, but do you think competent threat actors, such as government agencies who can tap undersea fiber optic cables, who control all the black boxes in the hidden rooms of all the major internet exchange buildings, are unwilling to attack those using HTTP connections?

anal_reactor 2y ago
If the traffic gets hijacked the attacker might change the contents of silly stories and that's absolutely disastrous! Imagine the horror if they misspelled some words!
- anonym29 2y ago
  You are precisely missing my point here - the attacker doesn't merely have the ability to modify the visual content on the page, but to inject arbitrary content of their choice into the response body, including JS scripts / WASM programs. This isn't some pedantic complaint about data integrity, it's a warning about this decision (allowing for HTTP rather than forcing HTTPS with only modern TLS versions supported) results in a possible vector for malicious remote code execution. Sure, they will be in a browser sandbox, but that's more than enough of a starting point to perform e.g. CSRF attacks, or malicious redirects to exploit kits or phishing pages, or set up a proxy using your connection to do other naughty things... to say nothing of sandbox escapes, cryptominers, or any other manner of JS / WASM nasties.
  - anal_reactor 2y ago
    The problem is, you're focusing on theoretical dangers that have like 0,0000000000000000001% chance of happening, instead of assessing what risks are actually probable. Basically the attitude "I don't allow my child to be out alone because there was a kidnapping case ten years ago on the other side of the country".
    - anonym29 2y ago
      I don't believe you're accurately quantifying the risk here. Remember, the barrier to pulling off an attack like this is extraordinarily low, and the list of contexts where it can potentially occur is considerable: potentialy any public wifi network without client isolation, having a naughty neighbor with a yagi antenna and too much free time, ISP/upstream routing entities being shady, or themselves being compromised to serve malware (several ISPs actually performed this exaxt technique to inject ads in the pages their customers were visiting years ago). Recall that my call to action is adding HTTPS support, and you're arguing against that. What's the counterargument against adding HTTPS? I've yet to hear a reasonable justification for not supporting it. It's incredibly easy, it's free, and it takes less than 3 minutes with Let's Encrypt / certbot.

anal_reactor 2y ago

If the traffic gets hijacked the attacker might change the contents of silly stories and that's absolutely disastrous! Imagine the horror if they misspelled some words!

anonym29 2y ago
You are precisely missing my point here - the attacker doesn't merely have the ability to modify the visual content on the page, but to inject arbitrary content of their choice into the response body, including JS scripts / WASM programs. This isn't some pedantic complaint about data integrity, it's a warning about this decision (allowing for HTTP rather than forcing HTTPS with only modern TLS versions supported) results in a possible vector for malicious remote code execution. Sure, they will be in a browser sandbox, but that's more than enough of a starting point to perform e.g. CSRF attacks, or malicious redirects to exploit kits or phishing pages, or set up a proxy using your connection to do other naughty things... to say nothing of sandbox escapes, cryptominers, or any other manner of JS / WASM nasties.
- anal_reactor 2y ago
  The problem is, you're focusing on theoretical dangers that have like 0,0000000000000000001% chance of happening, instead of assessing what risks are actually probable. Basically the attitude "I don't allow my child to be out alone because there was a kidnapping case ten years ago on the other side of the country".
  - anonym29 2y ago
    I don't believe you're accurately quantifying the risk here. Remember, the barrier to pulling off an attack like this is extraordinarily low, and the list of contexts where it can potentially occur is considerable: potentialy any public wifi network without client isolation, having a naughty neighbor with a yagi antenna and too much free time, ISP/upstream routing entities being shady, or themselves being compromised to serve malware (several ISPs actually performed this exaxt technique to inject ads in the pages their customers were visiting years ago). Recall that my call to action is adding HTTPS support, and you're arguing against that. What's the counterargument against adding HTTPS? I've yet to hear a reasonable justification for not supporting it. It's incredibly easy, it's free, and it takes less than 3 minutes with Let's Encrypt / certbot.