MITM Attacks: How to Detect and Stop Them in 2026

Article 5 of 6: Understanding TLS Security Series

A Man-in-the-Middle (MITM) attack occurs when an attacker secretly intercepts and potentially modifies communication between two parties who believe they are communicating directly. MITM requires network positioning first (ARP spoofing, DNS spoofing, rogue WiFi access point, BGP hijack) before the attacker can attempt TLS interception. The seven defences every SaaS team must layer in 2026 are: TLS 1.3 protocol, HSTS with preload to defeat SSL stripping, Certificate Transparency monitoring, certificate pinning for mobile apps, DNSSEC plus DNS over HTTPS, Encrypted Client Hello (ECH) to hide SNI, and 802.1X or WPA3-Enterprise on corporate networks. This article covers MITM attack techniques, TLS interception methods, detection strategies, and modern defenses including ECH.

Key findings

• MITM is a two-stage attack. Stage one is network positioning (ARP spoofing, DNS spoofing, rogue access point, BGP hijack). Stage two is TLS interception (SSL stripping, fake certificate, trusted CA proxy). Defences must address both stages.
• SSL stripping is defeated by HSTS plus the browser preload list. The first visit is still vulnerable to HTTP, which is why submission to hstspreload.org matters for high-value domains.
• Certificate Transparency logs detect rogue CA-issued certificates. Every publicly trusted certificate issued after 2018 must be logged in CT; monitor crt.sh or Certificate Transparency Reports for unauthorized certificates for your domains.
• HTTP Public Key Pinning (HPKP) is deprecated in browsers but certificate pinning is still used in mobile apps. Use SPKI (Subject Public Key Info) pins with at least one backup pin to avoid lockout on key rotation.
• Encrypted Client Hello (ECH) hides the SNI field that previously leaked the destination hostname even on TLS 1.3. Cloudflare enables ECH by default for all sites; Chrome and Firefox support it.
• Detection at the user layer is unreliable. Users rarely notice certificate warnings or extra latency. Infrastructure-level monitoring (CT log alerts, gateway MAC change alerts, DNS response anomalies) catches MITM faster than user reports.
• VPN on untrusted networks is the strongest personal defence. It moves the trust boundary from “the WiFi network I’m on” to “the VPN endpoint I control.”

Cybersecify is a founder-led penetration testing and security consulting firm based in Bengaluru, India, serving AI-first and API-first SaaS startups. We test MITM-vulnerability classes including TLS interception, certificate pinning bypass, HSTS misconfiguration, and protocol downgrade attacks in Web App, API, and Cloud Pentest engagements. For an example of the pentest deliverable that documents these findings, see our SOC 2 + ISO 27001 ready pentest report sample.

This article covers MITM attack techniques, TLS interception methods, detection strategies, and modern defenses including Encrypted Client Hello (ECH).

MITM Attack Overview

VICTIM  ────►  ATTACKER  ────►  SERVER
        ◄────            ◄────
Thinks talking     Intercepts, reads,     Thinks talking
to server          modifies traffic       to client

Attack Phase	Description
1. Positioning	Attacker places themselves between victim and server
2. Interception	Traffic is routed through attacker’s system
3. Decryption	Attacker terminates TLS, creates new connection to server
4. Inspection	Attacker reads/modifies plaintext data
5. Re-encryption	Data re-encrypted and forwarded to destination

MITM Defense Layers

Layer	Technology	Protection
Protocol	TLS 1.3	Encrypted handshake, mandatory ECDHE
Downgrade	HSTS + Preload	Prevents SSL stripping
Certificate	Certificate Transparency	Detects rogue certificates
Mobile	Certificate Pinning	Rejects unexpected certificates
DNS	DoH/DoT + DNSSEC	Prevents DNS spoofing
Privacy	ECH (Encrypted Client Hello)	Hides SNI from observers
Network	802.1X, WPA3-Enterprise	Prevents rogue AP, ARP attacks
VPN	Always-on VPN	Encrypts all traffic to trusted endpoint

1. Network Positioning Techniques

Theory: How It Works

Before intercepting TLS traffic, the attacker must position themselves in the network path. Several techniques exist:

ARP Spoofing (Local Network):

1. Attacker sends fake ARP replies to victim
2. Victim’s ARP cache maps gateway IP to attacker’s MAC
3. All traffic to gateway flows through attacker

DNS Spoofing:

1. Attacker responds to DNS queries before legitimate server
2. Victim resolves domain to attacker’s IP
3. All HTTPS traffic goes to attacker’s server

Rogue Access Point:

1. Attacker sets up fake WiFi with legitimate-sounding name
2. Victim connects to attacker’s network
3. All traffic passes through attacker-controlled router

Practical: Tools & Detection

# ARP Spoofing with arpspoof (dsniff)
arpspoof -i eth0 -t <victim_ip> <gateway_ip>
arpspoof -i eth0 -t <gateway_ip> <victim_ip>

# Using ettercap
ettercap -T -M arp:remote /<victim_ip>// /<gateway_ip>//

# Using bettercap
bettercap -iface eth0 -eval "set arp.spoof.targets <victim_ip>; arp.spoof on"

Reality: Detection & Prevention

Technique	Detection	Prevention
ARP Spoofing	ARP table changes, duplicate IPs	Static ARP entries, DAI on switches
DNS Spoofing	Unexpected DNS responses	DNSSEC, DNS over HTTPS (DoH)
Rogue AP	Duplicate SSIDs, weak signal	802.1X, WPA3, VPN
BGP Hijacking	Route changes, traceroute	RPKI, BGPsec

2. TLS Interception Techniques

Theory: How It Works

Once positioned, the attacker must break TLS encryption. There are several approaches:

SSL Stripping:

1. Attacker intercepts HTTP redirect to HTTPS
2. Maintains HTTP connection to victim
3. Creates HTTPS connection to server
4. Victim never sees HTTPS, so no certificate warnings

Fake Certificate:

1. Attacker generates certificate for target domain
2. Signs with self-signed or rogue CA
3. Presents to victim, and browser shows warning
4. If victim clicks through, attacker has plaintext

Trusted CA Interception (Corporate/Government):

1. Organization installs root CA on all devices
2. Proxy generates trusted certs for any domain
3. No warnings shown (legitimate use for monitoring)

Practical: Tools

# SSL Stripping with sslstrip
# Enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# Redirect HTTP to sslstrip
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

# Run sslstrip
sslstrip -l 8080

# TLS Interception with mitmproxy
# Generate CA certificate
mitmproxy  # Creates ~/.mitmproxy/mitmproxy-ca-cert.pem

# Install CA on victim device, then intercept
mitmproxy --mode transparent --showhost

Reality: Effectiveness

Technique	Warning?	Effectiveness	Defense
SSL Stripping	No padlock	High if no HSTS	HSTS preload
Self-signed cert	Yes (scary)	Low (obvious)	User education
Rogue CA cert	No	Critical	Cert pinning
Corporate proxy	No (trusted)	Total	Policy/legal

3. HSTS (HTTP Strict Transport Security)

Theory: How It Works

HSTS forces browsers to only use HTTPS for a domain, defeating SSL stripping attacks.

How HSTS Works:

1. Server sends HSTS header: Strict-Transport-Security: max-age=31536000
2. Browser remembers: “Only use HTTPS for this domain”
3. Future HTTP requests automatically upgraded to HTTPS
4. SSL stripping fails because browser refuses HTTP

HSTS Preloading:

First visit is still vulnerable to SSL stripping. Solution: HSTS preload list is hardcoded in browsers. Sites submit to hstspreload.org and are included in browser source code. The HSTS mechanism is defined in RFC 6797.

Practical: Configuration

# HSTS Header Examples

# Basic HSTS (1 year)
Strict-Transport-Security: max-age=31536000

# Include subdomains
Strict-Transport-Security: max-age=31536000; includeSubDomains

# Ready for preload list
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Nginx Configuration:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Check HSTS Status:

# Check if HSTS header present
curl -sI https://example.com | grep -i strict

Reality: Limitations

Limitation	Details
First Visit	Initial HTTP request still vulnerable; use preload
Expiry	If max-age expires, protection lost; use long max-age
Subdomains	Must explicitly include subdomains
Preload Removal	Removing from preload list takes months

4. Certificate Pinning

Theory: How It Works

Certificate pinning associates a host with its expected certificate or public key, preventing MITM even with a rogue CA.

What Can Be Pinned:

• Leaf certificate: most specific, breaks on renewal
• Intermediate CA: good balance, survives leaf renewal
• Public key (SPKI): survives cert renewal if key unchanged
• Root CA: least specific, highest risk if CA compromised

Practical: Implementation

Generate Pin Hash:

# Extract SPKI hash from certificate
openssl x509 -in cert.pem -pubkey -noout | \
  openssl pkey -pubin -outform der | \
  openssl dgst -sha256 -binary | base64

Mobile App Pinning (Android, OkHttp):

CertificatePinner pinner = new CertificatePinner.Builder()
  .add("example.com", "sha256/AAAAAAAAAAAAAAAAAAAAAA...=")
  .build();

Reality: Considerations

Consideration	Details
Backup Pins	Always include backup pin to prevent lockout on rotation
HPKP Deprecated	HTTP Public Key Pinning removed from browsers (too risky)
Mobile Apps	Still widely used in mobile apps (more controlled)
CT Alternative	Certificate Transparency provides similar protection

5. Encrypted Client Hello (ECH)

ECH encrypts the SNI field in Client Hello, hiding which website you’re connecting to. Combined with TLS 1.3 encrypted certificates and DoH, this provides near-complete privacy from network observers.

# Check ECH support
dig +short TYPE65 _https.cloudflare.com

# Check HSTS header
curl -sI https://example.com | grep -i strict

2026 ECH Adoption:

Platform	Status
Cloudflare	ECH enabled by default for all sites
Chrome	ECH supported since 2023
Firefox	ECH enabled by default

6. MITM Detection Techniques

Practical: Detection Methods

Network Layer Detection:

# Detect ARP spoofing
arp -a | sort  # Look for duplicate MACs
arpwatch -i eth0  # Monitor ARP changes

# Detect rogue DHCP
nmap --script broadcast-dhcp-discover

Certificate Analysis:

# Check certificate issuer
openssl s_client -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -issuer

# Check Certificate Transparency logs
# Visit: crt.sh, censys.io, or transparencyreport.google.com

Detection Indicators:

Indicator	Normal	MITM Suspected
Certificate Issuer	Let’s Encrypt, DigiCert, etc.	Unknown CA, self-signed
Gateway MAC	Consistent	Changes frequently
DNS Response	Expected IP	Different IP, fast response
Latency	Normal	Increased (extra hop)
CT Logs	Certificate present	Certificate missing

Users rarely notice MITM attacks. Detection is most effective at the infrastructure level with proper monitoring and automated alerting.

Key Takeaways

• MITM requires network positioning first (ARP, DNS, rogue AP)
• SSL stripping is defeated by HSTS + preload list
• Rogue CA certs detected by Certificate Transparency
• Certificate pinning protects mobile apps
• TLS 1.3 encrypted handshake hides more metadata
• ECH hides SNI for complete privacy
• Use VPN on untrusted networks
• Never click through certificate warnings

---

Previous: Article 4: TLS Attacks & Vulnerabilities

Next: Article 6: TLS Hardening Guide

This is part of our 6-article series on Understanding TLS Security.

MITM vulnerabilities are a core focus of our Web Application Pentest, API Pentest, and IoT Pentest. We test certificate pinning, TLS interception, and protocol downgrade attacks. Get a free security snapshot or view pricing.

Related: TLS 1.2 Deep Dive: Complete Handshake Breakdown, TLS Attacks and Vulnerabilities: A Pro Guide, SOC 2 + ISO 27001 ready pentest report sample.