Cryptographic Protocol Threat Model (MitM, Replay, Downgrade)

#When Math Meets the Real World: Protocol Failures#link

A protocol can use perfect encryption (like AES-256) and perfect keys, yet still be completely insecure. This is because attackers don't always try to 'break the math'; instead, they attack the *logic* of the protocol—how the keys are exchanged and how the messages are ordered.

Man-in-the-Middle (MitM) & Impersonation

The most classic threat. In a MitM attack, the adversary sits between the client and server. During a Diffie-Hellman exchange, the attacker establishes one shared secret with the client and another with the server. The client thinks they are talking to the server; the server thinks they are talking to the client. The attacker decrypts, reads, and re-encrypts everything.

Once the network layer is compromised via ARP spoofing, the attacker can use tools like `bettercap` or `mitmproxy` to strip SSL/TLS and force the victim to use plain HTTP.

Replay Attacks

An attacker doesn't need to decrypt a message to cause harm. In a Replay Attack, the adversary captures a valid encrypted request (e.g., 'Transfer $100 to Attacker') and sends it to the server multiple times. Since the message is validly encrypted, the server processes it repeatedly.

{
  "action": "transfer_funds",
  "amount": 100,
  "nonce": "a7b8c9d0e1f2",
  "timestamp": "2025-05-20T10:00:01Z",
  "signature": "..."
}

Downgrade Attacks

In a Downgrade Attack, the adversary interferes with the initial handshake. They trick the client and server into agreeing to use an old, broken version of the protocol (e.g., forcing TLS 1.3 down to SSL 3.0). Once the protocol is downgraded, the attacker can use known vulnerabilities like POODLE to decrypt the traffic.

• ▪Disable legacy protocols (SSLv2, SSLv3, TLS 1.0, 1.1)
• ▪Implement HSTS (Strict Transport Security)
• ▪Use 'SCSV' (Signaling Cipher Suite Value) to detect downgrades
• ▪Avoid 'Export' grade ciphers