Skip to main content

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​

Security_Assessment_ EnableTLS_FALLBACK_SCSV

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

Vulnerability information​

To avoid the issue of clients downgrading, you can use the TLS_FALLBACK_SCSV signal as a workaround. This workaround serves as a dummy fake cipher suite listed during the Client Hello message to the server. It is 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 is 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 does not, the latter will disregard the signal and attempt the connection.

Enable TLS_FALLBACK_SCSV​

When OpenSSL is used as a base for the SSL/TLS encryption (e.g., for an Apache or Nginx webserver), update it to the latest version. For example, the following versions are known to support TLS_FALLBACK_SCSV:

  • OpenSSL 1.0.1j
  • OpenSSL 1.0.0o
  • OpenSSL 0.9.8zc

E.g., run:

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 stated version and the server 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 is all the server knows. So what if one of those intermediate versions is not supported by the server and happens to be the highest version the Client supports?
In previous pentests, servers did not support TLS v1.1 but supported TLS v1.0 and TLS v1.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 is 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 TLS v1.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 does not understand 1.2, and the server does not want to speak 1.1. the two will never discuss it with one another.