The TLS Signaling Cipher Suite Value (SCSV) protects against TLS/SSL downgrade attacks such as POODLE. If enabled, the server ensures that the strongest protocol that both client and server understand is used.
Here’s what you need to know about the TLS_FALLBACK_SCSV signal, how it works, and how to enable it.
TLS_FALLBACK_SCSV Security Assessment
CVSS Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Why is TLS_FALLBACK_SCSV required?
During the SSL/TLS handshake between clients and servers, both parties advertise the highest supported protocol versions to select the one shared by both.
During the handshake and protocol version negotiation between servers and clients, certain buggy servers will stop and crash. The reason for a crash typically is the server’s inability to recognize a version suggested by the client that is higher than the version it supports. Instead of renegotiating to the highest mutually supported one, some servers will experience a connection error and crash.
In the past, browsers that didn’t yet support TLS_FALLBACK_SCSV would try to reconnect by using an older protocol version, such as SSL 3.0, to avoid a second crash. I.e., instead of reaching a consensus about the highest possible version, they would downgrade to one that is certain to work.
Unfortunately, falling back to a much older protocol version and connecting leaves servers and clients open for attacks. Moreover, attackers could deliberately exploit this mechanism of clients shifting to older versions via a man-in-the-middle interference.
By interfering with client attempts to use newer TLS versions, i.e., mimicking a server crash, attackers can make a client attempt weaker TLS connections or an SSL 3.0 connection, ideally. Once this connection is established, they can exploit all the vulnerabilities associated with a given protocol. For example, a BEAST attack can be launched against TLS 1.0 and SSL 3.0. In addition, a LUCKY13 attack is potentially also possible in those instances.
This is where TLS_FALLBACK_SCSV comes in to prevent protocol downgrade attacks from occurring.
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.
Is TLS_FALLBACK_SCSV a failproof solution?
Even if both clients and servers support the TLS_FALLBACK_SCSV signal, this does not guarantee that there can’t be other issues on the server-side that can break the connection.
Let’s imagine one of those broken servers that are prone to crashing when faced with versions it cannot understand. If, for example, such a server supports TLS 1.2 and 1.0 but doesn’t support TLS 1.1, whereas a client’s maximum protocol version is TLS 1.1, this could potentially lead to an unresolvable situation. The client would then constantly point to a higher version, but the server will not provide it and crash. This would force the client to downgrade and insert the signal to support a higher version. Once this is again attempted, the server would crash again, etc.
Alternatively, if a client can only go as high as SSL 3.0 and the server supports this protocol, the fallback signal is of no use, and the connection will be potentially exposed to attacks. It is essential to mention that the POODLE attack, in particular, works only with block ciphers in CBC-based cipher suites. If RC4 is the preferred cipher suite, such an attack is likely to fail in this case. Of course, supporting SSL 3.0 with RC4 is not desirable at all!
The above are possible scenarios in which TLS_FALLBACK_SCSV may not work. While they are not impossible, they are not particularly likely. Moreover, for a server that does not support weak protocols and cannot be forcibly downgraded, the fallback signal will have less impact on security. For this reason, it is good to implement the fallback signal but only alongside other security measures.
Prevention Guide
Learn how to detect and prevent different kinds of SSL/TLS vulnerabilities.
How to Enable TLS_FALLBACK_SCSV
Follow this guide to enable TLS_FALLBACK_SCSV:
OpenSSL
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
