Man-in-the-middle (MitM) attack

2. Man-in-the-middle (MitM) attack

A MitM attack occurs when a hacker inserts itself between the communications of a client and a server. Here are some common types of man-in-the-middle attacks:

Session hijacking:-

In this sort of MitM attack, the attacker captures a session between a confided customer and a network server. The attacking PC substitutes its IP address for the believed customer while the server proceeds with the session, trusting it is speaking with the customer.

For instance, the attack might unfold like this:

A client connects to a server.

    The attacker’s computer gains control of the client.
    The attacker’s computer disconnects the client from the server.
    The attacker’s computer replaces the client’s IP address with its own IP address and spoofs the client’s sequence numbers.
    The attacker’s computer continues dialog with the server and the server believes it is still communicating with the client.

IP Spoofing:-

IP spoofing is utilized by an attacker to persuade a system that it is speaking with a known, trusted entity and give the attacker admittance to the system. The attacker sends a packet with the IP source address of a known, confided in have rather than its own IP source address to a target host. The objective host may acknowledge the packet and follow up on it.

Replay:-

A replay attack happens when an attacker captures and saves old messages and afterward attempts to send them later, imitating one of the members. This sort can be handily countered with session timestamps or nonce (an arbitrary number or a string that changes with time).

As of now, there is no single innovation or design to prevent all MitM attacks. Generally, encryption and digital certificates give a compelling shield against MitM attacks, guaranteeing both the confidentiality and integrity of communications.

Yet, a man-in-the-middle attack can be injected into the middle of communications so that encryption won't help — for instance, assailant "A" blocks the public key of individual "P" and substitute it with his own public key. Then, at that point, anybody needing to send an encoded message to P utilizing P's public key is accidentally utilizing A's public key. Hence, A can peruse the message proposed for P and afterward send the message to P, encoded in P's genuine public key, and P won't ever see that the message was compromised. Moreover, A could likewise adjust the message before resending it to P. As should be obvious, P is utilizing encryption and thinks that his data is ensured yet it isn't, due to the MitM assault.

Things being what they are, how might you disclose sure that P's key has a place with P and not to A? Authentication specialists and hash capacities were made to take care of this issue. At the point when individual 2 (P2) needs to make an impression on P, and P needs to be certain that A won't peruse or change the message and that the message really came from P2, the accompanying technique should be utilized:


    1. P2 creates a symmetric key and encrypts it with P’s public key.
    2. P2 sends the encrypted symmetric key to P.
    3. P2 computes a hash function of the message and digitally signs it.
    4. P2 encrypts his message and the message’s signed hash using the symmetric key and sends the entire thing to P.
    5. P can receive the symmetric key from P2 because only he has the private key to decrypt the encryption.
    6. P, and only P, can decrypt the symmetrically encrypted message and signed hash because he has the symmetric key.
    7. He can verify that the message has not been altered because he can compute the hash of the received message and compare it with a digitally signed one.
    8. P is also able to prove to himself that P2 was the sender because only P2 can sign the hash so that it is verified with the P2 public key.