In cryptography, the man-in-the-middle attack (often abbreviated MITM), or bucket-brigade attack, or sometimes Janus attack, is a form of active eavesdropping in which the attacker makes independent connections with the victims and relays messages between them, making them believe that they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all messages going between the two victims and inject new ones, which is straightforward in many circumstances (for example, an attacker within reception range of an unencrypted Wi-Fi wireless access point, can insert himself as a man-in-the-middle).
A man-in-the-middle attack can succeed only when the attacker can impersonate each endpoint to the satisfaction of the other. Most cryptographic protocols include some form of endpoint authentication specifically to prevent MITM attacks. For example, SSL authenticates the server using a mutually trusted certification authority.
With the exception of Interlock Protocol, all cryptographic systems that are secure against MITM attacks require an additional exchange or transmission of information over some kind of secure channel. Many key-agreement methods have been developed, with different security requirements for the secure channel.
Example of an attack
First, Alice asks Bob for his public key. If Bob sends his public key to Alice, but Mallory is able to intercept it, a man-in-the-middle attack can begin. Mallory sends a forged message to Alice that claims to be from Bob, but instead includes Mallory's public key.
Alice, believing this public key to be Bob's, encrypts her message with Mallory's key and sends the enciphered message back to Bob. Mallory again intercepts, deciphers the message using her private key, possibly alters it if she wants, and re-enciphers it using the public key Bob originally sent to Alice. When Bob receives the newly enciphered message, he believes it came from Alice.
- Alice "Hi Bob, it's Alice. Give me your key"--> Mallory Bob
- Alice Mallory "Hi Bob, it's Alice. Give me your key"--> Bob
- Alice Mallory <--[Bob's_key] Bob
- Alice <--[Mallory's_key] Mallory Bob
- Alice "Meet me at the bus stop!"[encrypted with Mallory's key]--> Mallory Bob
- Alice Mallory "Meet me in the windowless van at 22nd Ave!"[encrypted with Bob's key]--> Bob
What did just happen?
- Alice sends a message to Bob, which is intercepted by Mallory
- Mallory relays this message to Bob; Bob cannot tell it is not really from Alice
- Bob responds with his encryption key
- Mallory replaces Bob's key with her own, and relays this to Alice, claiming that it is Bob's key
- Alice encrypts a message with what she believes to be Bob's key, thinking that only Bob can read it
- However, because it was actually encrypted with Mallory's key, Mallory can decrypt it, read it, modify it (if desired), re-encrypt with Bob's key, and forward it to Bob
- Bob thinks that this message is a secure communication from Alice
This example shows the need for Alice and Bob to have some way to ensure that they are truly using each other's public keys, rather than the public key of an attacker. Otherwise, such attacks are generally possible, in principle, against any message sent using public-key technology. Fortunately, there are a variety of techniques that help defend against MITM attacks.
Prevent an Man in the middle attack
Various defenses against MITM attacks use authentication techniques that are based on:
- Public key infrastructures
- Stronger mutual authentication, such as:
- Secret keys (which are usually high information entropy secrets, and thus more secure), or
- Passwords (which are usually low information entropy secrets, and thus less secure)
- Latency examination, such as with long Cryptographic hash function calculations that lead into 10s of seconds; if both parties take 20 seconds normally, and the calculation takes 60 seconds to reach each party, this can indicate a third party
- Second (secure) channel verification
- One-time pads are immune to MITM attacks, assuming the security and trust of the one-time pad.
- Carry-forward verification
The integrity of public keys must generally be assured in some manner, but need not be secret. Passwords and shared secret keys have the additional secrecy requirement. Public keys can be verified by a Certificate Authority, whose public key is distributed through a secure channel (for example, with a web browser or OS installation). Public keys can also be verified by a web of trust that distributes public keys through a secure channel (for example by face-to-face meetings).
See Key-agreement protocol for a classification of protocols that use various forms of keys and passwords to prevent man-in-the-middle attacks.
This information is taken from Wikipedia.org.