09-03: Exercises¶

Question¶

A client supports TLS 1.0 through TLS 1.3. A server also supports TLS 1.0 through TLS 1.3. An on-path attacker sits between them and can modify the initial, unencrypted handshake messages.

Describe a handshake manipulation the attacker could use to force both sides down to TLS 1.0 with a weak cipher, even though both actually support TLS 1.3.
What defense mechanism is specifically designed to detect this kind of manipulation?
What is the simplest, most robust fix — one that doesn't depend on any special detection mechanism at all?

Solution¶

Step 1: The downgrade manipulation¶

Per 09-05: Common TLS Attacks, the very first handshake messages (ClientHello, ServerHello) are sent before encryption is established, so an on-path attacker can read and modify them freely:

The client sends a ClientHello listing TLS 1.0–1.3 and a range of cipher suites.
The attacker intercepts this message and strips out everything except TLS 1.0 and a weak cipher suite, before forwarding a modified ClientHello to the server.
The server, seeing only TLS 1.0 and a weak cipher suite offered, has no way to know stronger options were ever proposed — it simply picks the best of what appears to be available and responds accordingly.
Both the client and server now believe they performed a normal negotiation and settled on TLS 1.0 with a weak cipher "because that's all that was mutually supported" — neither side has any direct evidence that options were removed in transit.

This sets up exactly the conditions historical attacks like POODLE exploited (see 09-05: Common TLS Attacks) once the connection is forced down to old, flawed cryptography.

👉 (1) The attacker strips strong version/cipher options out of the ClientHello before it reaches the server, forcing a negotiation down to the weakest options still listed.

Step 2: The detection mechanism¶

TLS_FALLBACK_SCSV is a special signaling value a client includes when it's specifically retrying a connection at a lower version (e.g., because a previous attempt at a higher version failed to connect). If the server sees this value but is actually capable of a higher version than what's currently being offered, that's a strong signal something is wrong — a legitimate client wouldn't retry at a lower version unless a higher one had already failed, and the server knows it never had a problem with the higher version. The server aborts the connection instead of completing a suspicious downgrade.

👉 (2) TLS_FALLBACK_SCSV-style downgrade signaling lets a server detect and refuse a connection that looks like a forced downgrade.

Step 3: The simplest, most robust fix¶

Detection mechanisms like TLS_FALLBACK_SCSV are useful, but they depend on specific client/server behavior (retry logic) and correct implementation on both ends. The far simpler and more robust fix is to remove the weak options from the list of things that can ever be negotiated in the first place:

If neither the client nor the server is willing to accept TLS 1.0/1.1 or weak cipher suites at all, there is nothing left in the ClientHello for an attacker to strip down to — the weakest thing either side would ever accept is already a strong configuration (TLS 1.2+ with modern ciphers).

This is exactly the recommendation in 09-06: TLS Best Practices & HTTPS: disabling old protocol versions entirely closes the downgrade attack surface structurally, rather than relying on detecting an attack that's already in progress.

👉 (3) Disable support for old TLS versions and weak cipher suites entirely on both client and server — an attacker can't downgrade a negotiation to options that were never offered.

Final Answer¶

The attacker strips strong version/cipher options from the ClientHello in transit, forcing both sides to settle for the weakest remaining shared option.
TLS_FALLBACK_SCSV lets a server detect a suspicious version fallback and abort.
The most robust fix is structural: disable old TLS versions and weak ciphers entirely, so there's nothing weak left to downgrade to.