The explanation I've seen before is that it doesn't really matter for websites that don't _want_ anything from you. No credentials, no login forms, no text entry fields.
Maybe there are edge cases associated with this?
Maybe there are edge cases associated with this?
Still worth creating a bit of a shield between you and the site to make it just hat much harder for anybody in the middle to inject anything / change anything.
Back before Lets Encrypt made it inexcusable to not have https, it was a common-ish prank to MITM all the HTTP traffic you could see and do something harmless like rotate images 180 degrees.
There are now alternatives, like zerossl for instance
But most importantly: it pushed ACME and all the automation blocks, DNS-based DCV and stuff
So now, lots (all ?) providers also let's you generate certificate (cloud provider and cdn and whatever)
In the end, no, let's encrypt hardly controls "most of the domains on the internet"
While it's highly unlikely that threat actors would be lurking in trusted networks and devices on such a network path, they definitely don't need to use shared WiFi or ARP spoofing if they have control of a core router or transmission line. That's the very essence of MITM attacks.
Knowledge of facts and history.
What leads people such as yourself to start a response this way? "I'll respond to you but first I'm going to feign ignorance of how you could even say that in a way that adds absolutely nothing to the discussion." I perceive this as exceptionally rude. Am I alone in that?
> does inherently allow undetected tampering by any middleman.
Yes. And did I describe methods by which you can hijack connections to /become/ the middleman? Perhaps you missed the subtle detail.
> That's the very essence of MITM attacks.
The popularized attacks you're describing became popular because they were done with the techniques I described in places like Starbucks and other businesses with open Wifi networks. Here it is, literally:
So, I am still unsure that you are clued in here, because the article you have linked to has nothing at all to do with tampering in-flight TCP streams, only sniffing them. Perhaps you do not understand how these principles differ. This shared WiFi scenario certainly permits eavesdropping on unencrypted channels, and that’s a danger that’s distinct from actual MITM.
You claim we’re describing the same thing but we are not.
> did I describe methods
No, actually you didn’t — you named one vector and one mostly unrelated LAN attack. ARP spoofing may be a stepping stone, but not really central.
The attack you describe happens at the application layer, in fact. It doesn’t even need to use TCP. You’re simply stealing someone’s credentials and reusing them in a new browser session. There’s really no way to legitimately describe this as “MITM” — or “tampering” at all. [Your Wikipedia article does not use these terms.]
And in a typical Starbucks installation, nobody would realistically attempt to tamper with in-flight TCP streams. Because that attack would involve some elaborate setup, presenting a higher challenge than the Firesheep attack. I am sure you could explain and describe the former, if you understand the underlying principles.
No, the classic MITM attacks on http do involve neither WiFi nor ARP, but simply interposing malicious code somewhere else on-path. [Actually it is not necessarily malicious, because NAT gateways work by modifying TCP streams too!] That’s why a newer name is called “on-path attack”. And you seem to have omitted that scenario from your comments.
You don't need ARP spoofing or anything like that to intercept a plaintext communication when you control the ISP
Yes, the IETF and Mozilla really put NSA in their place with SSL, but the publicized, primary reason for adoption was eCommerce.
As the NSF handed control of the backbone to Sprint and commerce was finally permitted, the vendors campaigned to secure http lest the consumer’s personal data and credit card details were snooped and scooped while in-flight.
The Internet was incubated in a high-trust environment and every collegiate sysadmin was secretly employed by the NSA (except for Chris Siebenmann who is a North Korean sleeper agent). Once they were able to receive paychecks from Jeff Bezos instead, they began installing malware on routers to replace porn with videos of dancing babies and kittens being totes adorbs.
SSL kept our credit cards safe from the NSA and our porn is no longer sponsored by the ASPCA. Whew.
Sure, your website may have unimportant stuff on it that nobody relies on, but do you want visitors to see ads in your content that you didn't put there?
Plenty. There are a lot of information-only websites where you might want to keep your visit to yourself.
To give an obvious example: some parts of the United States are trying very hard to make abortion impossible. The state government could mandate that ISPs MitM your traffic, and alert the police when you visit a website giving you information about the legal abortion clinics in a neighboring state. Guess you'll be getting a home visit...
The same is going to apply with looking up info on LGBT subjects, civil rights, Tiananmen Square, a religion not explicitly allowed by the state, whether Eurasia has always been at war with Oceania, and so on. Heck, even a seemingly innocent website visit could theoretically come back to haunt you years later. Just some bored scrolling on Wikipedia? Nope, you were planning a crime - why else were you reading pages about chemical warfare during WW I? That neighbor who died due to mixing bleach and ammonia was obviously murdered by you.
If it's unencrypted, you should assume it's being logged by someone nefarious. Are you still okay with it?
It's honestly surprising that anyone gets away with any significant crimes, given just how much potential evidence is recorded.
TLS is more important on sites that are just serving information. It's easy to reconstruct your train of thought as you click around.
Librarians have fought (and lost) to defend our privacy to read.
https://www.ala.org/advocacy/intfreedom/privacyconfidentiali...
Not to mention injected ads which used to be very common in the late 2000s.
It's a little bit like using Tor for some of your ordinary browsing (which I do) so that spy agencies can't infer everyone using Tor is doing something wrong.
I consider the integrity of messages to-and-from the web to be very important.
Many of us lived through days when ISPs or some other greedy middleman injected ads into unsecured web pages. They played DNS tricks too.
Imagine if you had an app download that could be maliciously modified in-flight.
Furthermore, a certificate can guarantee you’re not connected to an imposter. What if the TFA link was redirected to “abevigoda.com”? Catastrophe!