3 ms·
Friendly reminder that for any sites served over HTTP rather than HTTPS, anyone with access to the traffic between you and the server has the opportunity to inj
by anonym29 2y ago
Friendly reminder that for any sites served over HTTP rather than HTTPS, anyone with access to the traffic between you and the server has the opportunity to inject content of their choice into the page via a man-in-the-middle attack, including JS to be executed by your browser. That can include all manner of complex exploits, sandbox escapes, etc - regardless of the trustworthiness of the content producer themselves.
This is an inherent, unavoidable additional risk you are accepting when you retrieve content over HTTP instead of HTTPS - a risk that content producers are unknowingly foisting upon their viewers by neglecting to even offer their content over HTTPS.
The type of attack I've mentioned, a MiTM, is so trivial to pull off with freely available tools that teenagers were doing this decades ago - this is not a complex, sophisticated attack with a high technical knowledge barrier to carry out, this is something your 12-year-old nephew can do after watching a few youtube videos.
- deleted 2y ago[deleted]
- fragmede 2y agoThe technical competence to pull off this attack is low, but being in a position of privilege is difficult. I could kill someone by adding some poison to their food, but more importantly I'd have to poison food they're going to eat. I can trivially add posion to food I cook in my house, but as my victim isn't going to eat that food, that's pointless. Similarly, in order to "poison" someone else's Internet with a Monster in the middle (MitM) attack, you need to get in a privileged position so as to do that. For people using a smartphone on a cellphone data plan, getting in that privileged position is beyond the capabilities of most 12-year olds, as they'd have to have privileged access into your cell phone provider. If, however that 12-year old is running an insecure wifi AP that you're using to get to the Internet, you're a bit more at risk. However, the poison in this metaphor is more difficult. A trivial script injection to open a popup is easy to do, but actually doing something harmful is far harder. Aka procuring a poision that only gives you a molds headache in this metaphor is easy, but getting arsenic/something that steals your bank account credentials is hard. Chrome is well hardened against attack, so while bugs do exist, they're not trivial to find and exploit. Which doesn't mean they won't by, but it does mean it's far less likely your 12-year old nephew has 0-days to burn.
- anonym29 2y agoI 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 agoIf 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 agoYou 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 agoThe 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".