Man-in-the-Middle, Downgrade, and Replay

Now that you understand how TLS works, let’s look at how attackers try to break it. These are the three fundamental attack categories against TLS connections.

Man-in-the-Middle (MITM)

Imagine you’re passing notes to a friend in class, but the person sitting between you is secretly reading each note, copying it, and passing it along. They might even change the message before forwarding it. Neither you nor your friend knows the person in the middle is involved.

The attacker positions themselves between the client and server. They establish a TLS connection with the client (pretending to be the server) and a separate TLS connection with the server (pretending to be the client). They decrypt traffic from one side and re-encrypt it for the other.

sequenceDiagram
    participant C as Client
    participant A as Attacker
    participant S as Server

    C->>A: ClientHello
    A->>S: ClientHello (forwarded)
    S->>A: ServerHello + Real Certificate
    A->>C: ServerHello + Fake Certificate
    Note over C: Does the fake certificate pass validation?
    Note over C: If NO: browser warning, attack detected
    Note over C: If YES: attack succeeds silently

Why MITM usually fails: the attacker can’t forge the server’s certificate. They’d need the server’s private key or a trusted CA to sign a fake certificate. Browsers reject certificates that aren’t signed by a trusted CA.

When MITM works:

The user clicks through the browser warning (ignoring the security error)
The attacker controls a trusted CA (corporate environments install their own root CA on employee devices)
A CA is compromised and issues a fraudulent certificate (DigiNotar, 2011)

Downgrade Attacks

Say you and your friend can communicate in three languages: English, French, and Pig Latin. An attacker intercepts your first message where you list the languages you speak, and crosses out English and French. Your friend thinks you only speak Pig Latin, which is much easier for the attacker to understand.

The attacker modifies the ClientHello to remove strong cipher suites or downgrade the TLS version, forcing the connection to use weaker cryptography that the attacker can break.

TLS defends against this with the Finished message. The Finished message contains a hash of all handshake messages. If an attacker modified the ClientHello, the hash computed by the client won’t match the hash computed by the server (which saw the modified ClientHello). The handshake fails.

TLS 1.3 added an additional defense: if a TLS 1.3-capable server is forced to negotiate TLS 1.2, it includes a special sentinel value in the ServerHello random field. TLS 1.3-capable clients check for this sentinel and abort if they see it (indicating a downgrade attack).

Replay Attacks

The attacker records a legitimate TLS message and sends it again later, hoping the server processes it twice.

TLS prevents replay through the random values in ClientHello and ServerHello. Each session has unique random values, which feed into the key derivation. A replayed message from a different session won’t decrypt correctly.

The exception is 0-RTT in TLS 1.3, where early data can be replayed (as discussed in the 0-RTT chapter). This is a known limitation, and applications must handle it at the application layer.

Next: Heartbleed, POODLE, BEAST, and CRIME

← Previous Chapter Next Chapter →