Luke a Pro

Luke Sun

Developer & Marketer

🇺🇦
EN|简|繁
© 2015–2026 Luke Sun.
All rights reserved.

Man-in-the-Middle (MITM) Attack

| , 4 minutes reading.

1. Definition

A Man-in-the-Middle (MITM) attack occurs when an attacker secretly positions themselves between two communicating parties, intercepting and potentially modifying their communications without their knowledge.

Both parties believe they are communicating directly with each other, but in reality, all messages pass through the attacker, who can eavesdrop, modify, or inject new content into the conversation.

2. Technical Explanation

MITM attacks exploit the trust relationships in network communications. The attacker must accomplish two things:

  1. Interception: Position themselves in the communication path.
  2. Decryption (if applicable): Break or bypass encryption to read the content.

Common MITM Techniques:

  1. ARP Spoofing: Attacker sends fake ARP messages to associate their MAC address with the IP of the default gateway, causing traffic to route through their machine.

  2. DNS Spoofing: Attacker provides false DNS responses, redirecting victims to malicious servers.

  3. Rogue Wi-Fi Access Points: Attacker creates a fake Wi-Fi hotspot (e.g., “Free Airport WiFi”) that victims connect to.

  4. SSL Stripping: Attacker downgrades HTTPS connections to HTTP, intercepting data in plaintext.

  5. BGP Hijacking: Large-scale attack where internet routing is manipulated to redirect traffic through attacker-controlled networks.

What Attackers Can Do:

  • Read sensitive data (credentials, messages, financial info)
  • Modify data in transit (change transaction amounts, inject malware)
  • Impersonate either party (respond on behalf of the server)

3. Attack Flow

sequenceDiagram
    participant Victim
    participant Attacker as Attacker<br/>Rogue AP
    participant Server as Bank Server

    Note over Victim,Attacker: Victim connects to<br/>Rogue WiFi Hotspot

    Victim->>Attacker: DNS Query: bank.com
    Attacker->>Attacker: Intercepts DNS query
    Attacker-->>Victim: Returns attacker IP for bank.com

    Victim->>Attacker: HTTPS Request to bank.com

    Note over Attacker: SSL Stripping:<br/>Attacker connects to real bank<br/>via HTTPS but serves HTTP to victim

    Attacker->>Server: HTTPS Request forwarded
    Server-->>Attacker: HTTPS Response with login page

    Attacker-->>Victim: HTTP Response - login page

    Victim->>Attacker: POST credentials over HTTP
    Note over Attacker: Credentials captured in plaintext

    Attacker->>Server: Forward credentials via HTTPS
    Server-->>Attacker: Session token
    Attacker-->>Victim: Session token

4. Real-World Case Study: DigiNotar Breach (2011)

Target: Iranian Gmail users via fraudulent SSL certificates. Vulnerability Class: Certificate Authority Compromise / MITM.

The Incident: DigiNotar was a Dutch Certificate Authority (CA) trusted by all major browsers. In July 2011, attackers compromised DigiNotar and issued over 500 fraudulent SSL certificates, including one for *.google.com.

The Attack:

  1. Iranian ISPs (believed to be state-sponsored) used these fake certificates to perform MITM attacks.
  2. When Iranian users visited Gmail, they received the fraudulent certificate.
  3. Browsers showed a valid HTTPS connection (green padlock) because DigiNotar was trusted.
  4. All email traffic was intercepted and read by attackers.

How It Was Discovered: A security-conscious user in Iran noticed the certificate was issued by DigiNotar (not Google) and reported it. This led to an investigation revealing the massive breach.

Impact: DigiNotar was removed from all browser trust stores and went bankrupt within a month. This incident accelerated the adoption of Certificate Transparency and led to stricter CA security requirements.

5. Detailed Defense Strategies

A. HTTPS Everywhere (TLS/SSL)

Encrypt all communications to prevent eavesdropping.

  • HSTS (HTTP Strict Transport Security): Force browsers to only use HTTPS.
  • HSTS Preload: Include your domain in browser preload lists to prevent first-visit attacks.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

B. Certificate Pinning

Prevent attackers from using fraudulent certificates (even from compromised CAs).

  • Public Key Pinning: Application only trusts specific certificate public keys.
  • Certificate Transparency: Monitor CT logs for unauthorized certificates issued for your domain.
// Mobile app certificate pinning example
const validPins = [
  'sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=',
  'sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB='
];

C. VPN Usage on Untrusted Networks

Encrypt all traffic through a trusted tunnel when on public Wi-Fi.

  • Always-On VPN: Configure devices to automatically connect to VPN on untrusted networks.
  • Split Tunneling Caution: Avoid split tunneling which may leak some traffic.

D. DNS Security

Prevent DNS-based MITM attacks.

  • DNS over HTTPS (DoH): Encrypts DNS queries to prevent interception.
  • DNS over TLS (DoT): Alternative encrypted DNS protocol.
  • DNSSEC: Cryptographically signs DNS records to prevent spoofing.

E. Network Security Protocols

  • 802.1X Authentication: Require authentication before granting network access.
  • Dynamic ARP Inspection (DAI): Switch-level protection against ARP spoofing.
  • DHCP Snooping: Prevents rogue DHCP servers from redirecting traffic.

F. User Awareness

  • Certificate Warnings: Never ignore browser certificate warnings.
  • Verify Networks: Confirm legitimate Wi-Fi network names with staff.
  • Avoid Sensitive Operations: Do not access banking/email on untrusted networks without VPN.

6. References