51–60 of 62 posts
Earlier quoted context omitted.
Older than encryption? Encryption has existed since before the Roman empire. > It refers to literally a person intercepting your message before (or instead of) it reaching the intended audience. Every time somebody has pointed that out they have extracted that definition from the term opposed to referencing the term from a definition. It is similar to answering a question with only a restatement of the question.
MitM attacks have been around far longer than transport/network layer encryption has been commonly deployed, is what parent means. These days it's more commonly used to defeat encryption but there's plenty of attacks that don't really need it (e.g. ARP spoofing, etc etc)
Earlier quoted context omitted.
The OWASP definition is correct. The gist of a MITM is that each end of the transmission trusts that the malicious actor in the middle is the target destination. When this occurs at the application layer it is almost universally centered on encryption. Keep in mind that in TCP/OSI terms the web is an application riding the internet. Without encryption how do you trust that the destination is who they claim to be? MIT…
> The OWASP definition is correct. Okay. Your definition, with its additional encryption requirement, is at odds with the OWASP definition. > Without encryption how do you trust that the destination is who they claim to be? Signing? Or just ignorance? I agree that "trust" is a component, but it doesn't have to make sense. I can still fool you and the server to which you're connecting into thinking I'm the other party…
Not really. I did expound on this in the very comment you replied to.
> I agree that "trust" is a component, but it doesn't have to make sense.
Perhaps that is true if you are a hobbyist commenting on the internet. It does have to make sense in security management, though. The definitions of the terms are well understood in business and there are liabilities when associated terms are violated. That is why there are security certifications that are valued and recognized by the software industry, so that the people who do this for a living having a common shared understanding of the risks and penalties.
Earlier quoted context omitted.
Yes, technically because it's conducted by someone in the middle of the transport path, you can call it man in the middle. The problem is that if you call all attacks that, what do you call the attack where asymmetric key exchange is being replicated by some attacker in the middle? Also, it's possible to pull this particular attack off without being in the "middle",. For example, by using DNS cache poisoning or arp s…
> The problem is that if you call all attacks that, what do you call the attack where asymmetric key exchange is being replicated by some attacker in the middle? You use a more exact term. I don't see the problem.
This concept is commonly understood by security people and commonly confused by software developers. I suspect the failure is that for software developers all parts of a network are in the middle between their application and their end user, so anything in that nebulous space corresponds with the words comprising MITM. That line of thinking is reductio ad nausium.
Why would anyone use anything else than Chrome or Firefox on Android? I wouldn't even trust Samsung.
I believe things might work pretty differently when it comes to China, which is the main demographic of this browser
I really hope this substantially reduces the number of users, or Google takes the app down completely. The browser is ridiculously terrible: both from the user and the developer point of view. The browser constantly spams the phone with irrelevant, clickbait news articles/ads (and yet it's so popular). The developers (especially in India) cannot ignore the browser because of its large userbase, and then that's one mo…
Regular people don't stop using an app because it shows irrelevant articles, click baits. Facebook, YouTube trending are more "mainstream" examples of this.
Earlier quoted context omitted.
> The OWASP definition is correct. Okay. Your definition, with its additional encryption requirement, is at odds with the OWASP definition. > Without encryption how do you trust that the destination is who they claim to be? Signing? Or just ignorance? I agree that "trust" is a component, but it doesn't have to make sense. I can still fool you and the server to which you're connecting into thinking I'm the other party…
> Okay. Your definition Not really. I did expound on this in the very comment you replied to. > I agree that "trust" is a component, but it doesn't have to make sense. Perhaps that is true if you are a hobbyist commenting on the internet. It does have to make sense in security management, though. The definitions of the terms are well understood in business and there are liabilities when associated terms are violated.…
> Not really. I did expound on this in the very comment you replied to.
I agree with your expounding. Perhaps I'm not seeing where you addressed my concern, but these statements:
1. "Man in the middle only involves encryption."
2. "The OWASP definition is correct."
seem to be at odds, given that (3.) the OWASP does not exclude attacks on unencrypted channels (per their MiTM page). One of your statements (1 or 2) must be wrong, or my understanding of the OWASP definition (3) is wrong.
I'm not sure what to make of your response to my "trust" comment (though I agree with everything you said, it seems to be in a different context from the question). We're probably speaking past each other. Let me try to tease out the disagreement.
> The gist of a MITM is that each end of the transmission trusts that the malicious actor in the middle is the target destination. When this occurs at the application layer it is almost universally centered on encryption. Keep in mind that in TCP/OSI terms the web is an application riding the internet. Without encryption how do you trust that the destination is who they claim to be?
So does your definition of "trust" here _require_ encryption? Is encryption _explicitly_ required in a MiTM attack, or is it only required for "trust" (which I agree is necessary).
> Android apps "distributed via Google Play may not modify, replace, or update itself using any method other than Google Play's update mechanism. Likewise, an app may not download executable code (e.g. dex, JAR, .so files) from a source other than Google Play." Obvious question: why did this get approved, and will Google amend their process to close this loophole?
"It’s impossible to be sure that cybercriminals will never get ahold of the browser developer’s servers or use the update feature to infect hundreds of millions of Android devices." Apparently they didn't consider the same sentence would be just as valid if they replaced "browser developer" with Google... This is an example of the authoritarian security sensationalism that's far too common today, and it only leads to…
If you continue reading you find the key difference to the comparison you just made: > This unofficial update feature present in UC Browser can also be used by would-be attackers to perform man-in-the-middle attacks (MitM) attacks, potentially leading to remote code execution on compromised devices, because the app communicates with its servers using an unencrypted channel over HTTP. It's a lot easier to use the upda…
I have no problem with factual reporting of the risks; it's the scaremongering promotion of Google's walled-garden that irritates me the most.
Earlier quoted context omitted.
> Okay. Your definition Not really. I did expound on this in the very comment you replied to. > I agree that "trust" is a component, but it doesn't have to make sense. Perhaps that is true if you are a hobbyist commenting on the internet. It does have to make sense in security management, though. The definitions of the terms are well understood in business and there are liabilities when associated terms are violated.…
First, thanks for engaging! I appreciate getting corrected on this. > Not really. I did expound on this in the very comment you replied to. I agree with your expounding. Perhaps I'm not seeing where you addressed my concern, but these statements: 1. "Man in the middle only involves encryption." 2. "The OWASP definition is correct." seem to be at odds, given that (3.) the OWASP does not exclude attacks on unencrypted…