ISP: No you should definitely have ICMP available for testing.
SAAS Engineer: Leave it on so I can tell when your shit goes down without having to consult your service status page.
Sysadmin: I really dont care what you do, just enable it when you raise a complaint with your ISP so they can tell you what you broke.
Residential: Your TP Link hyper dreadnought super hawk that is taking up every inch of the 5ghz indoor spectrum in your home is probably already blocking icmp for you. Its probably also already part of a botnet. YMMV.
Dropping ICMP breaks path MTU discovery (PMTU). It's the biggest reason why sites break when accessed (or served) over VPNs. This is often mitigated on the server, or in NAT-ing routers, by clamping TCP MSS, but that doesn't really resolve the problem. It doesn't fix it for UDP, nor likely for double VPN scenarios, etc, plus you're just losing bandwidth that way.
Some people make fatalistic arguments that even if they allow ICMP, something downstream may not have, so it's futile. But the networks in the middle rarely if ever block ICMP; those engineers know better. The real issue is on the ends. If you're a sysadmin dropping ICMP, you're half the problem. Fix ICMP on your end, and half the problem goes away. The other half of the problem are those NAT-ing routers, firewalls, and VPNs that don't handle ICMP properly. You can't fix those, but plenty of residential and commercial equipment on the other end, as well as VPN setups, actually do the right thing. Don't make perfect the enemy of better.
the problem is ICMP can be abused for attacks like ICMP flood, ICMP smurf, because src.ip can be easily spoofed.
its very easy and cheap to saturate a link with flood traffic, but fixing this issue requires large investments in big expensive firewalls that can block these stupid attacks
You are absolutely correct, but also, I am already having to clamp MTU for most business customers anyway, for a hundred reasons.
The issue is that sysadmins make this the ISP's issue anyway. They wont do any kind of investigation but simply yell at the telco. Telcos are ready willing and able to clamp. Its as natural as breathing at this point.
The only thing that gets me is when the some small business refuses to enable ICMP for troubleshooting when they raise a complaint. You have to come to the table at least that far.
> small business refuses to enable ICMP for troubleshooting
Depending on your definition of small business, asking someone "hey can you enable ICMP real quick" is like asking them "hey can you build a rocket ship while skydiving?"
Comes from all sides. Mom and Pop running a small store, refuse on the grounds of not wanting to change a setting on their router.
Small as in <100 employees. The IT guy doesnt want to change anything, hes been there 20 years and never changed that setting. Or he needs to go through change management which he is also adverse to.
> Residential: Your TP Link […] is probably already blocking icmp for you.
If it does, it generally won't pass telco CPE certification, i.e. Comcast and the likes won't be selling it to you in any bundle. Blocking ICMP Fragmentation Needed / ICMPv6 Packet Too Big is a hard fail on all of those, other message types can vary.
(Source: I work in this area.)
[Ed.: to be clear, there is no single "telco CPE certification"; each telco decides this on their own. A bunch of them form groups/"alliances" though, and a lot of the certification requirements are the same everywhere.]
Which is ≈mostly≈ fine; I'm just saying people in appropriate places (deciding which CPEs get sold to you) have gotten rather touchy about the PMTU bits. And rightfully so!
I supported a mid size WISP for 2 years and something like 60% of the issues they sent my way were ultimately resolved with MSS Adjust or MTU clamping.
> Your TP Link hyper dreadnought super hawk that is taking up every inch of the 5ghz indoor spectrum in your home is probably already blocking icmp for you. Its probably also already part of a botnet
The more spiky black angular antennas you put sticking up on a router that makes it resemble a science fiction movie arachnid-form robot, the faster it goes. This seems to be the universal design language now.
For routers that consumers purchase themselves, the design language seems to have been optimized to look amazing and cool and grab the attention of someone browsing the aisles at the local Best Buy.
I bought a TP Link router to run in AP mode for WiFi 7. It has none of those antennae sticking out. It does have a little grid of LEDs on the front that I have set to the UwU face option though...
My newest router doesn't have any of that shit and works just as well, with at least as much range, as the one it replaced, which had six(!) of those insectoid antenna things.
I wouldn't be surprised if the damn antennas are just empty. They don't seem to serve any purpose.
They aren't for range, but for MIMO (exploiting that the signal bounces differently between the antennas either end of the connection, while some antenna pairs behave poorly, others may well be perfect, so it essentially matches them (through a mixing matrix, to be more abstract/generic) to form good pairs that are also independent from another, so they can simultaneously run different data streams over different antennas to severely increase speed.
It also compensates for interference dead spots when you hold your phone into such a spot.
The long sticks typically radiate in the plane normal to the stick, i.e., if you make them all perfectly vertical, they are focused to the same floor. Individual ones can be rotated readily to cover special spots, especially if you have more than 4 antenna.
Blocking ICMP tends to come with blocking ICMP Unreachables, that happens to handle Path MTU Discovery (PMTUD), which you definitely want on if you work around VPN's at all, or certain ISP's that might not allow a full 1500 byte frame. Microsoft loves to particularly set application traffic to Do-Not-Fragment, and this will play chaos on many Microsoft things if PMTUD is disabled around reduced MTU environments.
It's best left on at least inside a private/protected network.
Everybody sets traffic to Do-Not-Fragment. Nobody wants their routers to fragment packets anyway; you might as well ask to get a notification when too big packets are dropped.
Nobody wants to have their servers reassemble fragments, it's too much work; many servers just drop any fragments they do get. I ran servers pushing 20 gbps of downloads, and would receive on the order of two fragments per second. It looked legitimate, so I preferred not to disable fragment assembly, but I'd set the reassembly buffer as small as possible; there's no need to keep more than say 16 fragments... if you're getting more than a handful of fragments, it's ddos and that one guy with a weird network will just have to deal. They probably can't use any other sites anyway.
I am not a network engineer, but when I hear ICMP, I associate it with consuming CPU on my shitty router and DDos potential. I only block ICMP for unknown external traffic (response to packets not otherwise blocked by firewall, then aggressively rate limit that) and allow it internally. I used to go overboard in the past and learned how annoying it is to not being able to do a simple ping...
If people can send packets to you, they can DDoS your shitty plastic router CPU regardless of you blocking ICMP or not. And whether your router generates a reply is really ancillary to the question — so long as that reply isn't notably larger than the triggering packet. (Otherwise you're running a reflection amplifier and some people would like to have words with you.)
These days with cheap bandwidth about, the only way to really prevent DDoS is to catch them at the source(s). Hell, I have 25Gbit at home (Init7), I can blow entire small telcos off the internet. Once. Then Init7 terminates my service. And that's really the only thing that can prevent this…
Fair enough. For me personally it's not that big of a concern. I just remember from a previous network monitoring gig that using ICMP had a few problems with rate limiting. But that wasn't my cheap router at stake. It's probably just something that stuck with me and not that relevant in my context anymore.
Indeed. What I meant was that it's cheaper to drop than to generate a reply. But you are right, and I also mentioned in the other reply, that my router wouldn't stand a chance dropping or replying to a DDoS anyway, so probably this concern is not relevant in the home router context.
It's indeed to log you in to multiple Google properties at once. It's not needed for e.g. Gmail (since it's a subdomain under google.com) but YouTube is in its own domain so it has no access to google.com's cookies.
I turned off YouTube for my account using admin.google.com. Doing so causes Google to stop redirecting me to YouTube and back. Of course this also means I'm never logged in while visiting YouTube.
Yes, I noticed this. Perhaps due to different handling of logins on both the sites. This could be handled in the backend by not redirecting as well, but therd should have been design choices there.
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.
> 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.
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.
I am not sure what leads you to answer this way, but I assure you that HTTP, like any other unencrypted network traffic, does inherently allow undetected tampering by any middleman.
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.
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:
Well, I interpreted your reply as implying that the only vectors possible were shared WiFi or ARP spoofing. If you merely intended to offer two examples, then it makes more sense. But I am still not sure why your answers are so irrelevant!
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.
> Maybe there are edge cases associated with this?
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?
To be fair, TLS doesn't stop the authorities from performing dragnet searches. Just supeona Google for search keywords, mobile service providers for geofence data, DNS logs, IP logs from ISPs, etc. If that gives them enough for a warrant, they can get emails, SMS, browser history, account data, and detailed location logs. Not to mention license plate readers, surveillance cam footage and financial transactions.
It's honestly surprising that anyone gets away with any significant crimes, given just how much potential evidence is recorded.
Without TLS, sometimes still referred to as SSL, a webite's content can be modified by anyone controlling the network path. This includes ISPs and WiFi operators.
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?
In addition to what everyone else has said, having everything be encrypted means encryption isn't "special", there's no metadata that indicates that the communication contains secret data due to encryption. If people don't encrypt non-sensitive traffic, then sensitive traffic stands out. So there's a sort of civic duty element to enabling TLS (or using encrypted messaging, etc.).
The website might not be designed to have credentials or login forms, but now you have allowed attackers to place fake login forms on your website. And given the prevalence of password reuse for the general population, attackers can easily harvest real passwords this way.
Not to mention injected ads which used to be very common in the late 2000s.
Without TLS, people (service providers and intermediaries) can tell what pages I'm reading on your site. They can make the kind of inferences from these that get people convicted at trial.
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.
The good thing about that is that I don't have to do that because if you blanket block ICMPv6, IPv6 just won't work at all. No neighbor discovery, no default route ;D
I don't know people focus on blocking protocols when IP addresses are more useful. I've blocked most of DO's IP address space and it really cleaned up the logs.
ISP: No you should definitely have ICMP available for testing.
SAAS Engineer: Leave it on so I can tell when your shit goes down without having to consult your service status page.
Sysadmin: I really dont care what you do, just enable it when you raise a complaint with your ISP so they can tell you what you broke.
Residential: Your TP Link hyper dreadnought super hawk that is taking up every inch of the 5ghz indoor spectrum in your home is probably already blocking icmp for you. Its probably also already part of a botnet. YMMV.
> Sysadmin: I really dont care what you do
Dropping ICMP breaks path MTU discovery (PMTU). It's the biggest reason why sites break when accessed (or served) over VPNs. This is often mitigated on the server, or in NAT-ing routers, by clamping TCP MSS, but that doesn't really resolve the problem. It doesn't fix it for UDP, nor likely for double VPN scenarios, etc, plus you're just losing bandwidth that way.
Some people make fatalistic arguments that even if they allow ICMP, something downstream may not have, so it's futile. But the networks in the middle rarely if ever block ICMP; those engineers know better. The real issue is on the ends. If you're a sysadmin dropping ICMP, you're half the problem. Fix ICMP on your end, and half the problem goes away. The other half of the problem are those NAT-ing routers, firewalls, and VPNs that don't handle ICMP properly. You can't fix those, but plenty of residential and commercial equipment on the other end, as well as VPN setups, actually do the right thing. Don't make perfect the enemy of better.
the problem is ICMP can be abused for attacks like ICMP flood, ICMP smurf, because src.ip can be easily spoofed.
its very easy and cheap to saturate a link with flood traffic, but fixing this issue requires large investments in big expensive firewalls that can block these stupid attacks
You are absolutely correct, but also, I am already having to clamp MTU for most business customers anyway, for a hundred reasons.
The issue is that sysadmins make this the ISP's issue anyway. They wont do any kind of investigation but simply yell at the telco. Telcos are ready willing and able to clamp. Its as natural as breathing at this point.
The only thing that gets me is when the some small business refuses to enable ICMP for troubleshooting when they raise a complaint. You have to come to the table at least that far.
> small business refuses to enable ICMP for troubleshooting
Depending on your definition of small business, asking someone "hey can you enable ICMP real quick" is like asking them "hey can you build a rocket ship while skydiving?"
Comes from all sides. Mom and Pop running a small store, refuse on the grounds of not wanting to change a setting on their router.
Small as in <100 employees. The IT guy doesnt want to change anything, hes been there 20 years and never changed that setting. Or he needs to go through change management which he is also adverse to.
> Residential: Your TP Link […] is probably already blocking icmp for you.
If it does, it generally won't pass telco CPE certification, i.e. Comcast and the likes won't be selling it to you in any bundle. Blocking ICMP Fragmentation Needed / ICMPv6 Packet Too Big is a hard fail on all of those, other message types can vary.
(Source: I work in this area.)
[Ed.: to be clear, there is no single "telco CPE certification"; each telco decides this on their own. A bunch of them form groups/"alliances" though, and a lot of the certification requirements are the same everywhere.]
Inbound echo request and echo reply are almost always blocked in my experience.
Which is ≈mostly≈ fine; I'm just saying people in appropriate places (deciding which CPEs get sold to you) have gotten rather touchy about the PMTU bits. And rightfully so!
Absolutely.
I supported a mid size WISP for 2 years and something like 60% of the issues they sent my way were ultimately resolved with MSS Adjust or MTU clamping.
> Your TP Link hyper dreadnought super hawk that is taking up every inch of the 5ghz indoor spectrum in your home is probably already blocking icmp for you. Its probably also already part of a botnet
The more spiky black angular antennas you put sticking up on a router that makes it resemble a science fiction movie arachnid-form robot, the faster it goes. This seems to be the universal design language now.
For routers that consumers purchase themselves, the design language seems to have been optimized to look amazing and cool and grab the attention of someone browsing the aisles at the local Best Buy.
I bought a TP Link router to run in AP mode for WiFi 7. It has none of those antennae sticking out. It does have a little grid of LEDs on the front that I have set to the UwU face option though...
My newest router doesn't have any of that shit and works just as well, with at least as much range, as the one it replaced, which had six(!) of those insectoid antenna things.
I wouldn't be surprised if the damn antennas are just empty. They don't seem to serve any purpose.
They aren't for range, but for MIMO (exploiting that the signal bounces differently between the antennas either end of the connection, while some antenna pairs behave poorly, others may well be perfect, so it essentially matches them (through a mixing matrix, to be more abstract/generic) to form good pairs that are also independent from another, so they can simultaneously run different data streams over different antennas to severely increase speed.
It also compensates for interference dead spots when you hold your phone into such a spot.
The long sticks typically radiate in the plane normal to the stick, i.e., if you make them all perfectly vertical, they are focused to the same floor. Individual ones can be rotated readily to cover special spots, especially if you have more than 4 antenna.
I wish I knew more about RF engineering to comment, but the impression I get is that they cause more problems with interference than they solve.
No, don’t block ICMP.
Also, implement ssl because it’s trivial and prevents garbage isps from injecting ads.
Third, how about no ads to begin with?
Blocking ICMP tends to come with blocking ICMP Unreachables, that happens to handle Path MTU Discovery (PMTUD), which you definitely want on if you work around VPN's at all, or certain ISP's that might not allow a full 1500 byte frame. Microsoft loves to particularly set application traffic to Do-Not-Fragment, and this will play chaos on many Microsoft things if PMTUD is disabled around reduced MTU environments.
It's best left on at least inside a private/protected network.
Everybody sets traffic to Do-Not-Fragment. Nobody wants their routers to fragment packets anyway; you might as well ask to get a notification when too big packets are dropped.
Nobody wants to have their servers reassemble fragments, it's too much work; many servers just drop any fragments they do get. I ran servers pushing 20 gbps of downloads, and would receive on the order of two fragments per second. It looked legitimate, so I preferred not to disable fragment assembly, but I'd set the reassembly buffer as small as possible; there's no need to keep more than say 16 fragments... if you're getting more than a handful of fragments, it's ddos and that one guy with a weird network will just have to deal. They probably can't use any other sites anyway.
Path MTU discovery lives off ICMP. Block ICMP and expect connections to fail.
Clicked expecting a fat "NO", wasn't even surprised when I saw it.
Should I block port 80?
Port 53 isn’t necessary either if you have a good memory for numbers.
Yes. And port 443, too.
Should I disable the fan on my cpu?
In all seriousness, there is fan control software where you can request a speed of 0 when temperature is in a particular range.
Apple Silicon machines do this
Yes if the machine is operating in a vacuum.
Only if you leave the spacebar heating config set to off
I am not a network engineer, but when I hear ICMP, I associate it with consuming CPU on my shitty router and DDos potential. I only block ICMP for unknown external traffic (response to packets not otherwise blocked by firewall, then aggressively rate limit that) and allow it internally. I used to go overboard in the past and learned how annoying it is to not being able to do a simple ping...
If people can send packets to you, they can DDoS your shitty plastic router CPU regardless of you blocking ICMP or not. And whether your router generates a reply is really ancillary to the question — so long as that reply isn't notably larger than the triggering packet. (Otherwise you're running a reflection amplifier and some people would like to have words with you.)
These days with cheap bandwidth about, the only way to really prevent DDoS is to catch them at the source(s). Hell, I have 25Gbit at home (Init7), I can blow entire small telcos off the internet. Once. Then Init7 terminates my service. And that's really the only thing that can prevent this…
Fair enough. For me personally it's not that big of a concern. I just remember from a previous network monitoring gig that using ICMP had a few problems with rate limiting. But that wasn't my cheap router at stake. It's probably just something that stuck with me and not that relevant in my context anymore.
Block icmp don't even fix the cpu issue though, the router still use cpu to decide which packet should be blocked.
If you really care about the cpu usage, you should drop raw traffic instead (when dos from certain ip is detected)
Indeed. What I meant was that it's cheaper to drop than to generate a reply. But you are right, and I also mentioned in the other reply, that my router wouldn't stand a chance dropping or replying to a DDoS anyway, so probably this concern is not relevant in the home router context.
Its like me blocking youtube on hosts file or even on Pihole or related manually. I realize blocking youtube BREAKS a lot of things in the network.
What does blocking youtube break, aside from youtube?
There's a YouTube domain that's somehow a load-bearing part of Google's OAuth login flow.
I’ve never understood this (and really would like to). Why on earth does Google redirect to YouTube and then back to Google when logging in…
The only reason I can think of is to sync user session cookies across domains?
It's indeed to log you in to multiple Google properties at once. It's not needed for e.g. Gmail (since it's a subdomain under google.com) but YouTube is in its own domain so it has no access to google.com's cookies.
I turned off YouTube for my account using admin.google.com. Doing so causes Google to stop redirecting me to YouTube and back. Of course this also means I'm never logged in while visiting YouTube.
I guess it's the same reason I go through 4 login screens whenever I want to login to my Microsoft account... Legacy
I can confirm: it’s because of the syncing session cookies across domains.
I do believe it works if you block just the youtube.com domain and not *.youtube.com
You already know the reason.
In additional to youtube.com, in many cases, they redirect to many countries specific domain as well (e.g google.co.jp)
Youtube is common enough that they want to login on the same flow
Other than Chrome browsers don't support third party cookies by default.
Perhaps they want to force companies to not block YouTube.
Yes, I noticed this. Perhaps due to different handling of logins on both the sites. This could be handled in the backend by not redirecting as well, but therd should have been design choices there.
shouldiimplementssl.com
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?
> 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.
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.
That also requires either a shared wifi network or ARP spoofing. It's not something that HTTP itself inherently allows.
I am not sure what leads you to answer this way, but I assure you that HTTP, like any other unencrypted network traffic, does inherently allow undetected tampering by any middleman.
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.
> I am not sure what leads you to answer this way
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:
https://en.wikipedia.org/wiki/Firesheep
Well, I interpreted your reply as implying that the only vectors possible were shared WiFi or ARP spoofing. If you merely intended to offer two examples, then it makes more sense. But I am still not sure why your answers are so irrelevant!
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.
> Maybe there are edge cases associated with this?
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?
To be fair, TLS doesn't stop the authorities from performing dragnet searches. Just supeona Google for search keywords, mobile service providers for geofence data, DNS logs, IP logs from ISPs, etc. If that gives them enough for a warrant, they can get emails, SMS, browser history, account data, and detailed location logs. Not to mention license plate readers, surveillance cam footage and financial transactions.
It's honestly surprising that anyone gets away with any significant crimes, given just how much potential evidence is recorded.
Without TLS, sometimes still referred to as SSL, a webite's content can be modified by anyone controlling the network path. This includes ISPs and WiFi operators.
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?
In addition to what everyone else has said, having everything be encrypted means encryption isn't "special", there's no metadata that indicates that the communication contains secret data due to encryption. If people don't encrypt non-sensitive traffic, then sensitive traffic stands out. So there's a sort of civic duty element to enabling TLS (or using encrypted messaging, etc.).
The website might not be designed to have credentials or login forms, but now you have allowed attackers to place fake login forms on your website. And given the prevalence of password reuse for the general population, attackers can easily harvest real passwords this way.
Not to mention injected ads which used to be very common in the late 2000s.
Without TLS, people (service providers and intermediaries) can tell what pages I'm reading on your site. They can make the kind of inferences from these that get people convicted at trial.
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...
Remember the C-I-A triad of security.
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!
thankfully its pingable ¯\_(ツ)_/¯
$ ping shouldiblockicmp.com PING shouldiblockicmp.com (52.92.225.139) 56(84) bytes of data.
64 bytes from s3-website-us-west-2.amazonaws.com (52.92.225.139): icmp_seq=1 ttl=241 time=75.3 ms
No IPv6 though.
Maybe you should buy shouldiblockicmpv6.com...
The good thing about that is that I don't have to do that because if you blanket block ICMPv6, IPv6 just won't work at all. No neighbor discovery, no default route ;D
I unapologetically block ICMP from sources I consider to be trash.
Nothing worth keeping has broken as a result.
If you consider specific sources to be trash, why would you accept anything from them? Just block them completely…
Yes, I block them completely, including ICMP.
I also block outgoing to those sources (as destinations).
I don't know people focus on blocking protocols when IP addresses are more useful. I've blocked most of DO's IP address space and it really cleaned up the logs.
[dead]
Yes
That's why I only use urinals with dividers, to block ICUP