How to Enable TLS_FALLBACK_SCSV

The TLS Signaling Cipher Suite Value (SCSV) is protection against TLS/SSL downgrade attacks. If enabled, the server ensures that the most robust protocol that both client and server understand is used.

Security Assessment

CVSS Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

What is TLS_FALLBACK_SCSV and how does it work?

To avoid the issue of clients downgrading, a workaround was found that would serve as a “dummy” or fake cipher suite listed during the Client Hello message to the server. This workaround is the TLS_FALLBACK_SCSV signal. It was designed as a mechanism to avoid a server crash due to an unsuccessful handshake and protocol version negotiation.

Essentially, the signal lets the server know that the client supports a higher version than the one it is currently advertising and that a previous attempt at a connection failed for some reason. In this way, the server is informed of a better version being available and does not crash due to this information. 

Furthermore, by being notified that the client supports a higher version, the server will issue an “inappropriate_fallback” alert and abort the connection attempt to reattempt to establish a more secure connection.

But what if there is a man-in-the-middle actively interfering with client connection attempts? As long as TLS_FALLBACK_SCSV is supported both on the client and the server side, this will prevent the attacker from downgrading to insecure protocols since the server will know that a different version can be used and will not establish another one. As such, this signal serves to protect against any downgrade attempt.

What’s important to note is that to work, TLS_FALLBACK_SCSV must be enabled on both the client and server sides. So if the client supports it, but the server doesn’t, the latter will disregard the signal and attempt the connection.

apt-get update; apt-get upgrade # Debian / Ubuntu
yum update                      # RHeL / CentOS
pacman -Syu                     # Arch Linux

Assumptions and effects:

The draft RFC states that the server MUST refuse the connection if the maximum protocol version the server supports is higher than the one advertised within the Client Hello with the TLS_FALLBACK_SCSV signal. This assumes that the server supports all protocol versions between the Client’s stated version and the server’s maximum. What can the server infer about the Client? The Client supports at least one protocol version higher than that within the Client Hello. But that’s all the server knows. So what if one of those intermediate versions isn’t supported by the server and happens to be the highest version the Client supports?
In previous pentests, servers didn’t support TLSv1.1 but supported TLSv1.0 and TLSv1.2. Imagine a client that supports TLSv1.1 at best, so it starts with a TLSv1.1 connection. TLS allows the server to respond, saying effectively, “sorry, can’t do that, I can do TLSv1.0″. But suppose it’s one of those buggy servers for which the downgrade fallback was intended. In this case, the connection fails unexpectedly, and therefore the browser attempts the link again, using TLSv1.0 with the TLS_FALLBACK_SCSV signal. The server then refuses the relationship as its full TLS version is 1.2 and assumes the Client can do better. But the Client doesn’t understand 1.2, and the server doesn’t want to speak 1.1. the two will never discuss it with one another.