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 i

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.