Talk:Man-in-the-middle attack/Archive 1

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
Archive 1 Archive 2

The initial secure channel dispute

I disagree with your (David Jablon's) edits on the MITM page. You make it sound as if public key encryption can be secure in an enviroment where an attacker can perform widespread tampering ('either eavesdropping or tampering or both').

I was trying to point out that if you fear a MITM attack (as the designers of SSL/TLS did) you need a physically secure channel for the initial exchange. After Jablon's edits, that point was lost. -- Nroets 10:27, 12 July 2005 (UTC)

I tried to address some of your concerns on my talk page. (These concerns and follow-up discussion are now copied here.) "A physically secure channel for an initial exchange" is just one way to prevent MITM attack, so it is incorrect to say that "you need" it.
"Public key encryption" refers to a fairly narrow subcategory of "public key cryptography", with the latter term embracing a wide variety of tricks. Many different methods use public key cryptography in very different ways to create secure channels in environments where an enemy has full control over the communication channel, given some pretty-well-defined meanings of the word "secure".
In my edits I was trying to show some of the variety of ways that is done. Some use an *initial* (prior) secure channel, as you suggested, but others use a secure channel established after the fact. And "secure" doesn't necessarily imply "private". And some work with keys, others with passwords, etc. Some are two-party, others three or more. Etc.
In any case, I don't see how any points in your edits were lost. Both versions still have a clear reference to the need for a separate "secure" channel. And I don't see how either your text or mine limited "secure" to meaning "physically secure".
Furthermore, I don't see how your text implied that "public key {encryption|cryptography} cannot be secure in an environment where an attacker can perform widespread tampering". If that's what you intended to say, I cannot agree with that remark without further explanation.
That said, I agree that discussing the concept of physical vs. cryptographic security could help to clarify things. If you want to take a pass at fixing it to restore or expand on your viewpoint, feel free to do it on the page or in private email to me. -- David Jablon 10:57, 21 July 2005 (UTC)
Ok, I should not have used the word "physical" (on this page). And I'm not saying my version of the MITM page was faultless.
But people read long Wikipedia articles very fast and they often have very little background. So when you close the 'need for authentication' paragraph with something about public key cryptography, they assume it can solve the problem.
The first sentence (All cryptographic systems ... require an additional exchange ... of some kind of authentication information ...) only applies to public key cryptographic systems. The same goes of the title of the paragraph. I've indicated on the MITM talk page that I feel the page should also be kept applicable to secret key systems.
You were hinting that there are usefull (real world) systems where the secure exchange (transmission) need not be in the beginning (initial). If so, can you give an example. If not, can we use the word 'initial' in the paragraph ? -- Nic Roets 11:34, 22 July 2005 (UTC)
First, public key techniques can be used to solve the problem, and so can symmetric techniques. I think the text says this. But, in at least an historical sense, MITM attack is created by a mis-application or misunderstanding of public key cryptography, so I think it makes sense to highlight such issues.
Regarding the sentence ("All cryptographic systems ..."), I think it clearly applies to both symmetric and asymmetric systems. Regarding real world systems, useful or otherwise, I really wasn't trying to hint anything one way or another. I was correcting an error of fact. Diffie-Hellman, and many other public key systems (e.g. PGP, SSH) may be used in an effectively anonymous manner, where at a subsequent time the parties securely verify, preferrably out-of-band, the values of a shared DH key, or exchanged public keys, to retroactively prove that no MITM was ever present. -- David Jablon 10:59, 22 July 2005 (EDT)
Well for symmetric systems authentication is only half the story. Now we have clarity, I'll fix the page. -- Nic Roets 16:25, 22 July 2005 (UTC)

Interlock Protocol

As I explained to Shellreef, the interlock protocol also requires an initial transfer over a secure channel. -- Nic Roets 18:48, 27 July 2005 (UTC)

Not necessarily -- Jeff Connelly 03:18, 6 August 2005 (UTC)

Spelling of article title wrt hyphens

Shouldn't this article be renamed "man-in-the-middle attack"? Ehn 23:26, 23 January 2006 (UTC)

Yeah, I think so. I'd be bold, but the target page has been edited, so it needs to be deleted to make room for this. I've listed it for speedy deletion. —Simetrical (talk • contribs) 06:44, 24 January 2006 (UTC)
OK, I've moved the article and fixed all redirects, as well as the spelling in the article text. Ehn 15:05, 24 January 2006 (UTC)

Why focus on public key issues ?

IMHO the article should start by identifying all the attacks a good system should defend against, and then say how such a system could work :

  • Impersonation (highlighting the need for a reliable way to distribute root certificates or secret keys)
  • Evesdropping
  • Modification of messages for which the attacker can guess the plaintext.
  • Replaying of messages.
  • Synchronization of clocks, or some other technique to prevent the attacker from delaying selected messages.
  • The attacker is able to 'simulate' communications breakdowns. So a well designed system should not assume anything from the absence of messages from the other side.

The current article focus on a public key system, but non-public key systems exist fighting all the issues I mentioned. Nroets 21:20, 16 Jun 2005 (UTC)

I agree that symmetric systems can and should be stated as being able to solve the problem. However, MITM is historically related to mis-understanding or mis-application of public key cryptography, and I think it is important for the MITM page to discuss how this is a preventable problem in public key systems. --David Jablon 11:21, 22 July 2005 (EDT)
This article isn't about cryptographic attacks in general - it's about the MITM attack. It should discuss what weaknesses that particular attack exploits, perhaps, but a general description is probably outside the scope of this article. Graft 06:03, 23 July 2005 (UTC)
Having only just noticed this comment by Nroets, I'll reply some months after it was made. Perhaps someone doing some archaeological digging will benefit.
Crytographic system design is unique (to my knowledge anyway) amongst all engineering design disciplines in being unable to assume the operating conditions (eg, Mallory's knowledge, resources, abilities) are constant (see cryptographic engineering). So the suggestion that a WP article (not this one as Graft noted above) shold list the attacks to be resisted is a bit fanciful, and applies not at all to the real world problems of crypto system design. Mallory may figure out something new tomorrow... And you can't espect to know anything about it today, and may not even know the day after tomorrow, as Mallory will not be doing much talking about things. Cf, US break into Purple during WWII. Only from Congressional hearings after the War did the Japanese learn that traffic had been (and was being) read. They promptly changed away from Purple. ww 18:13, 18 February 2006 (UTC)

So which article *is* appropriate for listing (known) kinds of cryptographic attacks in general? I agree that "man-in-the-middle attack" is not the right article, but that sort of information is encyclopedic enough to go in at least one article, right? I agree that it is (theoretically) not possible to know all possible attacks -- just as it is not possible to know the complete List of Presidents of the United States from 1789 to 2099. However, I think we should still list all the ones we know about. It should be possible to *classify* all possible attacks, known and unknown, by listing what we *want* a cryptosystem to do -- any successfull attack must cause a cryptosystem to fail in at least one of those ways. -- 23:22, 30 November 2006 (UTC)

TV show Malcom in the middle

The TV show "Malcom in the middle" article does not mention the MITM acronym. —The preceding unsigned comment was added by Touisiau (talkcontribs) 09:02, 4 April 2007 (UTC).

How is this possible in IP?

What mechanism could be used on the Internet to intercept messages? Wouldn't you have to have direct access to routers? And don't only ISPs and the government generally have that? If you're worried about one of those snooping, I can understand, but how could some random Joe hacker pick up your message? —Simetrical (talk • contribs) 00:45, 30 December 2005 (UTC)

You're assuming all routers are secure. Try [1] on for size. Also, I don't see why, in this day and age, one shouldn't be worried about governments and ISPs snooping and consider this a significant cause for more concern than "random Joe hacker". Graft 19:50, 30 December 2005 (UTC)
I can speak to this, im Michael Lynn, read that link if you need to know why; there are a number of ways you can get MITM, first is to get it at layer 1, an example of this was my work on AirJack on 802.11, another is ARP posioning, then we move on to other issues, like hacking routers, remember its not always about hacking the router that is already between you, if I take control of the right router I can change my advertisements to make my route more favorable for dynamic routing schemes, likewise I can DoS attack other routers you're using to increase the chance that you route through me, thats all very doable --Michael Lynn 09:25, 4 April 2007 (UTC)

I don't see any obvious link to the promised part two. What exactly could you do with a router? Tell it to forward all packets going to a specific IP address or something? Okay, I can see where you might want to secure your passwords and whatnot. But how common are such attacks? The only hacking attacks I generally hear about tend to be basic virus spreading and stuff like that, things infecting clients and occasionally servers (then generally by means of clients). Even if it's possible to hack routers, surely personal computers are much easier targets; how many people bother hacking routers?

As for the government and ISPs snooping, those fall into something of a different category. I don't have any reason to care if the government or my ISP has the administrator password to some computer-game forum I run or something, since the one could do a lot more than screw with my bulletin board and the other won't do anything for fear of lawsuits. Although some might be unhappy with programs like ECHELON, you have to admit that for an average person, the hacker out to steal your credit card number is a much more immediate threat. —Simetrical (talk • contribs) 11:23, 3 January 2006 (UTC)

I can speak to this as well, I've hacked routers, big ones and small ones (in my lab of course), if I take control of the router I can tunnel all traffic for your host (or a collection of hosts) back to another machine where I filter, change, and/or block any content there, I can also do this all local on the router itself with no need to do the forwarding game. Once I've done that I can play lots of games, I can pretend to be your bank, etc...but perhaps the worst thing I can do is to break any weakly authenticated encryption you're using, a tool that came with something I used to maintain called AirJack (the tool was KrackerJack) did this very thing to break a weakly authenticated (read as password authentication) IPSEC tunnel over 802.11, so yes the threats are very real if you have something an attacker wants (on the other hand, you probably dont)... --Michael Lynn 09:25, 4 April 2007 (UTC)
I fail to see your point. There are people who want secure communications. Other people want to break those communications. Secure cryptographic protocols are one important way to avoid that. Consider competing governments, e.g. the USSR and the US back in the day. The Soviet ambassador wants to send a secure communication to Moscow. The NSA wants to intercept it via MITM. Simple enough? Just because it doesn't apply to YOU does not mean it's not an important cryptographic problem. Why does this have to be relevant to the "average person"? Graft 17:53, 3 January 2006 (UTC)

I wasn't suggesting it had to be. I was just asking if it was, for personal reference (and maybe to add to the article). I see people worried about SSL, etc., and wonder whether it's really that important. —Simetrical (talk • contribs) 09:26, 4 January 2006 (UTC)

S, I'm afraid you're committing a common, and classic, error in security / crypto analysis. This is not, in real respects, a ranking of threat problem, but an identification of any threat problem. For, you see, the problem isn't which attack zMallory is likely to undertake against you (or whether he will find you worthy of bothering with at all, another even more common classic evaluation error) but that you can't know beforehand (and often afterhand either) what Mallory will do (or is even likely to do). In such a condition of ignorance, one must merely observe that, if an attakc exists, Mallory might use it. And for your purposes, you'd best assume he will use it.
I think it was Anderson in Security Engineering (or maybe Schneier in Crypto-Gram) who noted that protecting a house against a break-in usually involves good doors (maybe steel even), door locks, deep screws and maybe metal shields on the strike plates, perhaps reinforced windows and window opening mechanisms, alarms, glass breakage sensors, infrared beams, ... But, against thieves with a little more imagination than the usual run (ie, with chainsaws) none of this is very effective however well (and expensively) done. They'll just go straight through the walls. Those with a little more cash on hand might use a recipro saw (the big straight in things, not a little jig saw type) and leave a little less mess. But most of those require wall current which might not be available if it were dead to kill the alarm system. Gas powered chain saws are independent of all that. Leave a bigger mess, but unless you're Bernie Rhodenbarr who specialized in surreptuity, this doesn't mean much. You won't have to clean up the mess, so ...? ww 18:29, 18 February 2006 (UTC)
An incredibly obvious vector for MITM attacks is on the source or target machines; a virus that intercepts the packets right there. That can be a lot easier on a secure machine than many other ways, including especially ISP servers or corporate internet gateways. --User;Pokeme444 20:50 Mar 20 2010 (UTC) —Preceding unsigned comment added by Pokeme444 (talkcontribs)


Is a different term used when the attacker is female? I'm not sure about usage.--Sonjaaa 22:00, 25 October 2007 (UTC)

Good one. (talk) 16:25, 20 February 2008 (UTC)

Generally, no. English has a long history that the male singular (depending on context) includes both. Some ojbject on grounds that such linguistic tradition is evidence the it's users are being sexist. Others think such objections are on par with objections to gender assignment of particular nouns in languages (like the Romance tongues) which have gender agreement rules. These last regard objections as mostly a excess of political or feminist correctness. ww (talk) 23:09, 17 March 2008 (UTC)

Too much crypto talk

The article has an awful lot of discussion about MITM with regards to public key cryptography. MITM doesn't have anything directly to do with cryptography. MITM attacks must be happening all the time for in-the-clear wireless connections currently, and I think that's what the article needs to be about. The fact that there may be holes in some crypto solutions that allow a MITM attack is secondary. (talk) 16:25, 20 February 2008 (UTC)

This is a good point. MITM is typically considered in the context of cryptography because cryptography usually aims to protect the confidentiality and integrity of a communications channel, something that a plaintext channel doesn't. If I use an unsecured channel, I do so (whether I know it or not) without regard to the possibility of a MITM attack (or indeed any other form of tampering), however, if I use a secure channel, I have increased expectations, so MITM becomes more pertinent to cryptography precisly because it is something that cryptography purports to offer protection against (and as we find time and time again, doesn't) pcrtalk 01:14, 23 February 2008 (UTC)
In the modern security context, MITM is indeed a cryptographic issue. Without an attempt to create a secure channel (broadly available only via crypto) a MITM attack is essentially trivial. For instance, a successful surreptitious wire tap of a telephone line is similarly trivial since the listener will immediately understand overheard conversations. Pacaro is correct I think, though this point should perhaps be made in the article. ww (talk) 23:13, 17 March 2008 (UTC)

How can PKI protect against a MITM attack?

If the attacker only wants to eavesdrop on the communication, doesn't alter packets, and so on, then what good a certificate from a CA does? I fail to see the solution for the problem of copying/relaying/proxying everything.

Here's a hypothetical scenairo of this. Alice goes to, but Evil Mallory has the control of that domain (either DNS spoofing or simply controls a router somewhere along the route to or Mallory controls Alice's DNS server or a route to Alice's DNS server, but Alice can reach the original CA of the site.) Then Mallory goes to, gets a copy of their site with their certificate. Then sends the whole package to Alice. Alice then sees that the certificate is valid for, issued by the original's CA. Alice can even request for a validity check via OCSP and Alice'll find that everything is ok.

Where's the flaw in my scenairo? Or is this a valid attacking scheme? Thanks. PAStheLoD (talk) 00:32, 24 July 2008 (UTC)

It works something like this: the CA certifies that public key X belongs to the legitimate operator of, so upon receiving the key and certificate Alice knows that the key is legitimate (and not a substitution by Mallory). Alice encrypts a random number with that public key and sends it over the wire. Only the real can decrypt it, and at that point they share a secret unknown to Mallory which they can use to protect subsequent traffic. -- BenRG (talk) 01:39, 24 July 2008 (UTC)
Thanks, that's really simple and brilliant. :) PAStheLoD (talk) 22:48, 26 July 2008 (UTC)

The need for an additional transfer over a secure channel

I'm not sure whether this adorable little story is actually relative to this article. Is it not better to put it into another article like "cryptography" or something where you can then place all upcoming improvements or improvements/suggestions you like to see implemented together ? It is really hard to understand the attack with this confusing story in place. KVDP (talk) 09:43, 2 October 2008 (UTC)

Unfortunately, the names are standard in cryptology circles. I'll look at adding a more non-crypto-geek friendly version. --Pokeme444 22:03, Mar 20, 2010 (UTC)

"Example of a successful MITM attack against public-key encryption"

This should be renamed. The example given makes NO attack against the public key encryption itself, but is an attack on insecure key exchange. If Alice and Bob meet in person to exchange public keys once, there is no future attack of this nature possible. Alvis (talk) 06:17, 9 November 2008 (UTC)

The attack is against the protocol, not against the encryption itself. Graft | talk 20:40, 10 November 2008 (UTC)

Wifi man in the middle attack in first paragraph

Not sure how eavesdropping an unencrypted wifi connection constitutes a man in the middle attack. Am I missing something here? (talk) 23:37, 12 November 2009 (UTC)

The operator of the wifi access point can intercept and inject packets. It's supposed to be an example of a situation where you can conduct a MITM attack without being a government or a telecommunications company. -- BenRG (talk) 17:56, 13 November 2009 (UTC)


interesting...ur explaination and examples has made me understand man in the middle attacks in a public key system

So you won't be meeting me at the windowless van on 22nd then? (talk) 21:52, 23 April 2010 (UTC)

Category: Vulnerable to man-in-the-middle attack

I think there should be a Category: Vulnerable to man-in-the-middle attack, containing those applications (and other tools) that are the subject of an article and are known to be vulnerable to MITM attack, such as downloadable software that isn't signed by the publisher, and for which secure hashes aren't available. Many popular applications are vulnerable.

Likewise, I think there should be a Category: Invulnerable to man-in-the-middle attack for technology that is resilient in the face of MITM attack. Most operating systems fall in this cateogry. Thoughts, pro or con? Would lists be better? --Elvey (talk) 23:28, 6 May 2010 (UTC)


SSL is vulnerable to MITM. See Christopher Soghoian, Sid Stamm, Matt Blaze, Bruce Schneier —Preceding unsigned comment added by (talk) 17:01, 27 September 2010 (UTC)


It occurs to me that Eve should be Mallory. Yes? Graft 04:03, 9 Sep 2004 (UTC)

Yep, I've changed it. — Matt 17:12, 9 Sep 2004 (UTC) changed it back to Eve, without explaining why (the comment identifies the section and nothing more), so I've reverted the change. - DPJ, 2006-01-18 22:51 UTC
For some reason it has been changed to Charles, so I changed it to Mallory. --Phantom784 16:54, 18 July 2006 (UTC)
Eve is more than standard. Why should it be Mallory? Bender2k14 (talk) 17:39, 25 March 2011 (UTC)

The tendency is that Eve is used for Eavesdropping, while Mallory is used for Mallicious attacks. Since MITM is malicious, Mallory is fitting using this reasoning. But these aren't hard and fast rules and I've never heard anyone expression a passionate opinion on the subject. Skippydo (talk) 21:08, 25 March 2011 (UTC)

Impossibility of fixing this problem

I think it should be mentioned that this problem is theoretically (but not practically) impossible to fix. Any mechanism to avoid this problem is itself a key exchange that can be attacked with MITM. -- Myria 16:48, 21 Sep 2004 (UTC)

Does anyone have a reference explaining why this is so? Thanks! Ehn 23:25, 23 January 2006 (UTC)
It is not obvious to me whether or not MITM is impossible to detect/avoid. Why do you think it is impossible to fix? The interlock Protocol was designed to stop MITM attacks, but apparently it is possible for some MITM attacks to succeed against it. Do you have some reason for thinking we'll never discover a better algoithm than the interlock protocol? If you have some alternative to the interlock protocol that works better against MITM attacks, I would really, really like to see that. So far, the best protocol I've seen is the "Merkle protocol" -- distribute your public key across many different media (newspaper, TV, radio, various web pages, etc), in hopes that Mallory won't be able to insert himself in *all* of them, and misses at least one. -- 23:22, 30 November 2006 (UTC)
the real problem is that to secure against MITM you need strong authentication, and for that authentication to work you need some sort of out of band communication of credecials that you can trust; likewise you could both share credencials of a trusted third party that can vouch for you (thats how PKI is supposed to work), but at some point you have to have a secure out of band communication of credencials or you can't trust the authentication (thus you cant trust MITM protection) explain further, without any out of band communication you are, in effect, trying to authenticate someone you don't know, at best you can authenticate that they are the same people you spoke with last time (this is what ssh does) and that is often adiquate for most users but it is not the same... --Michael Lynn 09:33, 4 April 2007 (UTC)
It is possible to fix, assuming you have a trusted root certificate server, like Verisign. They can sign the public keys of Alice and Bob, who can then sign messages they send. Since an attacker can't sign with Alice or Bob's key (leaving out of the equation the possibility of getting the private key and certificate, or compromising the root certificate). Then the main issue of trust becomes the signing authority; to the best of my knowledge the root certificate of a major signer like Verisign has never been compromised, has it? If so I think we'd see at least SOME attacks happening with it... Additionally, one-time pad text can be sent in the clear, assuming security of that pad. People, there's always a weakness somewhere, and usually it's the user or the developer who doesn't quite understand security. But there's always a weakness SOMEWHERE. The question of security comes down to how hard you want to make it for someone to crack; if it is sufficiently hard, it is deemed "secure" to at whatever level you're looking for. The solution posted here make it very hard: compromise Verisign. By that definition, the MITM attack is pretty well busted. --User:Pokeme444 8:38, 20 March 2010 (UTC)

I would agree with the original poster. This is always going to be a problem as long as someone has access to both the encrypted data as well as the keys that were exchanged. One example would be the NSA in the United States collecting all information sent over the Internet and cellular networks, or by any organizations which have access to critical routers. By having access to all that information, obtaining someone's key and using it to decrypt a saved or live data stream would be easy. Someone being able to intercept both the encrypted traffic as well as the key would be rare for an "outsider" as they would have to first become a middle point to do the interception, but for someone to do it inside existing Internet infrastructure would be trivial. Only using encoding which takes extreme amounts of processing power to break, and exchanging keys in a truly secretive way, will help at least postpone existing infrastructure middle-points from deciphering data. Swiftpaw (talk) 06:51, 29 June 2011 (UTC)

"Beyond Cryptography"... essay?

Opening line: "MITM should be seen as-" Immediately a hundred thousand red flags go off in my mind as I read this. I've tried to read quite a bit of Wikipedia FAQs and such, being a relatively new user to the editing fields, but nothing that I've seen is particularly suited for red-flagging particular sections to the public aside from asserting it in the talk section.. anyone else feel this is an issue? I really do feel the rest of the page is fine (I'm no expert on the subject) but I'm honestly concerned about this section.

I guess if it's not clear, my problem is that the phrase 'should be seen as' is not just heavily opinionated, but literally is suggesting that an opinion is fact, or is the right way to look at things. The rest of the section seems to follow this pattern, and while I have no problem with the opinion presented being, in fact, presented, it should obviously do so entirely objectively, i.e. "some people believe" or something. But I probably don't need to tell anyone here that.

Thanks for reading this concern, and I sincerely apologize if I missed something in plain sight regarding how to handle this issue. Varietyworks (talk) 18:28, 22 May 2012 (UTC)

Thank you. I agree, and have deleted the unreferenced paragraph in question. Socrates2008 (Talk) 21:22, 22 May 2012 (UTC)


The following appears to be false a quick Google search shows that neither bucket brigade attack or Janus attack is a commonly used term to refer to a man in the middle attack. Most of the references to those terms cite this article.

The man-in-the-middle attack also known as a bucket brigade attack, or sometimes Janus attack.

— Preceding unsigned comment added by (talkcontribs) 19:42, 2 January 2013‎ (UTC)

I've removed them. I don't think that they should be added back without a good citation. Quietbritishjim (talk) 23:38, 28 June 2013 (UTC)

terminology not gender matched

Should this term be renamed to "Person in the middle attack"? heh heh. I mean either that, or "Edith" should be "Edward". =)

I agree! Why do we tolerate such sexism here? Women can also be deceptive or dishonest. —Preceding unsigned comment added by (talk) 02:35, 26 May 2010 (UTC)

Enough with the trolling, I propose this article to be moved to "Middleperson attack". This term is already used in some literature, it's gender-neutral and also alot catchier. -- (talk) 12:18, 19 September 2013 (UTC)

Belkin Router example

While the router may be useable for a MITM attack, simply diverting requests or intercepting and replying directly with nagware doesn't constitute a MITM attack. MITM implies a lack of user awareness of the process. HistPhd (talk) 15:19, 28 April 2014 (UTC)

CAPTCHA crowd sourcing is not MITM

Using porn surfers to complete CAPTCHA isn't really a MITM, it might involve 3 parties but the surfer is just doing labour for the spammer, they aren't participating in the communication only providing solutions to CAPTCHA as work to access free content. — Preceding unsigned comment added by (talk) 23:09, 16 June 2014 (UTC)

Need for real world examples

If you asked for a list of C buffer over-runs or SQL code-injection flaws that have actually been exploited in the wild, you would need one of those comic-strip things where one person winds the paper onto a huge roll whilst the other writes the list. Conversely, when I asked a very experienced coder working on https implementations for an example of a verified, real-world MITM attack which led to a nontrivial data leak, he could not give me one single example. It is not that MITM is impossible to do, it's more that unless you are sending data via a dodgy carrier network (Third world hotel WiFi?) it is unlikely that a hacker would have the opportunity to perform a MITM, since in most cases it would mean physically infiltrating a data center, or perhaps tapping a fibre optic cable. Neither of which is easy.

As the page header says, Encyclopedic content must be verifiable. In the absence of any verified instances, maybe this article should say that MITM is a theoretical risk of an unknown level of likelihood. --Anteaus (talk) 22:17, 20 July 2015 (UTC)

The section "implementations" lists some tools that perform man-in-the-middle attacks. The existence of these tools is of course verifiable and hence encyclopedic. Opinions, whether man-in-the-middle attacks are a really important threat or just some theoretical risk, don't belong in the article. 2A02:120B:2C71:9BD0:2D4C:FF61:1EC7:9324 (talk) 07:58, 21 July 2015 (UTC)

"Turing porn farm"

Is this really a MITM attack? It doesn't seem like anyone is intercepting any communication. Mverleg (talk) 11:01, 13 August 2015 (UTC)

I agree it is not. There is nobody in the middle, in that the target is not passing through a hostile attacker. Rather a 3rd party is being used to gather information needed from a human. I think it should be removed as a misleading example. Chillum 16:55, 13 August 2015 (UTC)

Flaw in chess analogy

The current lede uses a chess analogy to give a rough idea of how MiM works, but it makes a much too simplistic and erroneous conclusion: "She plays the entire game this way and cannot lose." That would only be true if grandmasters never lose, but they certainly and often do — against each other, which is exactly what this analogy sets up. A more accurate statement would be that each grandmaster not only finds supposed-novice Mallory exhibiting unexpected skills, but (and here's the real analogy) might actually be able to identify the grandmaster against whom they're really playing by their moves. In fact, that's the point — the successful MiM is indistinguishable from the claimed identities in each direction. I leave it to some far less verbose than me to express this succinctly in the lede paragraph. ~ Jeff Q (talk) 01:56, 2 August 2016 (UTC)

@Jeffq: I removed it earlier today. Another issue is that the grandmasters know they're playing Mallory, whereas in a real MiM, the middleman is supposed to be completely transparent.--Jasper Deng (talk) 19:08, 15 October 2016 (UTC)


Revision 761294455, done by an IP address (visible here: ) seem to be vandalism. It mostly removes words and changes some others to unrelated or simply incorrect ones. (talk) 21:27, 25 January 2017 (UTC)

-Major concern, or meme ?

The question has arisen in some IT discussion groups as to whether MITM attacks are a genuine issue, or more in the nature of a meme. You find countless repetitions of the alleged dangers of MITM, yet few verifiable instances of such attacks exist. That might be because individual attacks are hard to identify and quantify.. or it might be because they are rare. The issue here is that when a meme is repeated enough times, and especially in enough textbooks, it takes on a life of its own.

I'm talking here about genuine data interception on-the-wire. Whether malware residing on a client computer or endpoint server can constitute a MITM is a moot point. I would say no, it is simply a stealer or modifier of data. A MITM attacks the data carrier medium. In any case, most of the protective measures against MITM attacks do NOT protect against malicious endpoint software. Opinions on this welcome, of course.

There is little doubt that in some circumstances, MITM risks are present. For example, when using hotel WiFi in some countries. In a more general case though, the risks possibly need to be quantified. It may well be that when using trustworthy data carriers they are a negligible concern as compared to, say, social engineering attacks, or exploitation of software vulns. This would not be a surprise finding, since the latter two are easier to arrange than to gain physical access to data handling equipment. --Anteaus (talk) 19:55, 10 February 2017 (UTC)

Semi-protected edit request on 24 February 2017 (talk) 17:11, 24 February 2017 (UTC)
Not done: as you have not requested a change.
Please request your change in the form "Please replace XXX with YYY" or "Please add ZZZ between PPP and QQQ".
Please also cite reliable sources to back up your request, without which no information should be added to, or changed in, any article. - Arjayay (talk) 17:32, 24 February 2017 (UTC)

Major vandalism

On January 21, an IP editor made numerous unhelpful edits to this article, and another. I have attempted to correct some of them, but there are many more. Comfr (talk) 00:08, 16 July 2017 (UTC)