A TLS downgrade attack is prevented by a combination of client-side and server-side mechanisms that ensure a secure connection, even if an attacker tries to force a weaker one.
Let’s see this in action. Imagine you’re trying to visit example.com.
Your browser, before even attempting to connect, might have a record of previous interactions with example.com. If example.com has previously told your browser to always use TLS (HTTPS), your browser will refuse to even try an HTTP connection. This is HSTS (HTTP Strict Transport Security).
Here’s a simplified look at an HSTS header a server might send:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
max-age=31536000: This tells your browser to enforce HTTPS forexample.comfor one year.includeSubDomains: This extends the rule to all subdomains ofexample.comas well (likewww.example.com,api.example.com).preload: This is a more advanced directive. If a site includespreload, the site owner can submit their domain to browser-maintained HSTS preload lists. Browsers ship with these lists, meaning they’ll enforce HTTPS for these sites from the very first visit, even before receiving an HSTS header.
Now, what if an attacker is on the network between you and the server and tries to intercept your initial request, perhaps by forcing your browser to talk HTTP instead of HTTPS? HSTS, especially when preloaded, stops this cold by refusing to even initiate an HTTP connection.
But HSTS primarily prevents initial downgrades. What if you’ve never visited example.com before, or the HSTS policy hasn’t been applied yet? The attacker might try to intercept the TLS handshake itself.
This is where SCSV (Signaling Cipher Suite Value) comes in. SCSV is a special value sent within the Client Hello message during the TLS handshake. It signals that the client is trying to establish a secure connection but is aware that a downgrade might be attempted.
Consider a simplified TLS handshake. Your browser (client) sends a ClientHello to the server. This message lists the cipher suites (encryption algorithms and key exchange methods) it supports. The server then picks one that both client and server support and sends it back in its ServerHello message.
If an attacker intercepts this, they could try to remove strong cipher suites from the list your browser thinks it’s sending, or manipulate the server’s response to force a weaker cipher suite.
With SCSV, your browser includes a special, non-negotiable cipher suite value: 0x0005 (TLS_FALLBACK_SCSV). If the server receives a ClientHello with TLS_FALLBACK_SCSV and the ServerHello selects a cipher suite that is weaker than the strongest cipher suite the client originally supported (and that the server also supports), the server must terminate the connection. It knows a downgrade attack is in progress.
The server-side implementation of SCSV checks if TLS_FALLBACK_SCSV is present in the client’s supported cipher suites. If it is, and the chosen cipher suite is not the strongest mutually supported one, the server rejects the connection. This prevents the attacker from successfully forcing a weaker, less secure connection.
The beauty is that SCSV doesn’t require any new cipher suites to be invented. It’s a signaling mechanism within the existing handshake. Both the client and server simply need to be configured to understand and act upon this specific value.
HSTS and SCSV work in tandem. HSTS ensures clients prefer and are forced to use HTTPS from the outset, especially for sites they’ve visited before. SCSV provides a crucial fallback mechanism during the handshake itself, detecting and thwarting attempts to downgrade the connection’s security parameters if HSTS hasn’t already prevented the downgrade.
The next concept you’ll likely encounter is certificate pinning, which adds another layer of defense against man-in-the-middle attacks by ensuring clients only trust specific certificates.