Are TLS Version Fallbacks Really Secure?

What is SSL? 

Secure Sockets Layer (SSL) is a cryptographic protocol that provides communication security over the Internet. SSL encrypts the data transported over the network, using cryptography for privacy and a keyed message authentication code for message reliability.

What is TLS? 

Transport Layer Security (TLS) is a standard protocol that is used to provide secure web communications on the Internet or on intranets. It enables clients to authenticate servers or, optionally, servers to authenticate clients. It also provides a secure channel by encrypting communications. TLS is the latest version of the Secure Sockets Layer (SSL) protocol. SSL is the predecessor to TLS.

What is TLS/SSL handshake?

When you are accessing any https website in web browser, in the first 200 milliseconds before the web page loads in the browser TCP three-way handshake and TLS/SSL handshake will get established which actually determines how sender and receiver shall encrypt their communications over the internet. Every SSL/TLS connection begins with a “handshake” – the negotiation between sender and receiver determines how the connection is secured by negotiating the suitable cipher suite supports by both client and server. A cipher suite is a combination of three algorithms (Key exchange algorithm, Data exchange algorithm, and Message authentication algorithm) used to secure their transaction in verifies the server and establishes that a secure connection is in place before beginning the actual transfer of data.
Client: The highest TLS version I support is 1.2.
Server: I too support TLS 1.2 so let’s use TLS 1.2 protocol to secure our communication.
[TLS 1.2 connection will be established.]

What is TLS Version Fallback?

Say if a client tries to communicate with a server using TLS 1.2 and if it is not supported by the server. The client will retry the connection by downgrading from TLS 1.2 to TLS 1.1. If TLS 1.1 also not supported by the server then retry with TLS 1.0 and again with SSL v3 and so on. A client supporting everything from TLS 1.0 to TLS 1.2 would start trying to establish a 1.2 connection, then a 1.1 connection, and if even that failed a 1.0 connection.
Client: The highest TLS version I support is 1.2.
Server: I only support TLS 1.1 so let’s use TLS 1.1 protocol to secure our communication.
[TLS 1.1 connection will be established.]

What is TLS Version Intolerance?

TLS version intolerance means certain web servers terminate the connections if they see a TLS protocol version they don’t know. In the TLS/SSL handshake process what happens client tries to connect with a protocol version unknown to the server. Should the client insist on any specific version and not agree with the one picked by the server it will have to terminate the connection. This is purely a server bug or server side issue. Unfortunately, there are a few web servers and network devices such as load balancers in the middle of a path between client and server implement TLS version negotiation incorrectly. Herewith provided few scenarios below.
Client: The highest TLS version I support is 1.3.
Server: ALERT! TLS/SSL Handshake failure. I don’t know that version.
[Connection will be terminated.]
Client: The highest TLS version I support is 1.3.
Server: TCP FIN! I don’t know that version.
[Connection will be terminated.]
Client: The highest TLS version I support is 1.3.
Server: (I don’t know this version so let’s just not respond. Connection will get timeout after two or three retries)
[Connection will hang.]

How and Why TLS Version Fallbacks Are Insecure?

Poodle (Padding Oracle on Downgraded Legacy Encryption) and Drown (Decrypting RSA using Obsolete and Weakened Encryption) attacks are the reason for TLS/SSL lower version protocols insecure to use which makes an attacker have access to personal information such as passwords and cookies. In a man-in-the-middle (MITM) attack, an attacker could downgrade an encrypted TLS session forcing clients to use SSL 3.0 and then force the browser to execute malicious code. This code sends several requests to a target HTTPS website, where cookies are sent automatically if a previous authenticated session exists. This is a required condition in order to exploit this vulnerability. The attacker could then intercept this HTTPS traffic, and by exploiting a weakness in the CBC block cipher in SSL 3.0, could decrypt portions of the encrypted traffic. PCI Council released version 3.1 of their Data Security Standard (DSS) has decided that SSL and TLS 1.0 can no longer be used after June 30, 2016.


Sometimes the connection can be downgraded by an MITM (man in the middle attack), by sending alerts or TCP packets to the client or blocking packets from the server. If a client detects whether the downgrade was initiated by an MITM then the client will include 'TLS_FALLBACK_SCSV' Cipher suite in the list of cipher suites that it supports in the TLS handshake process, server then realize that this is a repeated connection attempt, but this time with a version lower than the highest it supports, because previous TLS handshake attempts failed for some reasons (not due to the network glitches). If the server supports a higher TLS protocol version than advertised by the client in the client hello packet, the server must abort the connection by responding with a new Alert defined by the RFC called Alert (Level: Fatal, Description: Inappropriate Fallback) thus preventing and protect us from attackers forcing the TLS downgrades attack. Both, the client and server need to support this cipher suite at their end in order to make it work.


Despite this being a server-side bug/issue browsers will get all the blame if they can’t communicate with a particular website over https protocol. TLS_FALLBACK_SCSV cipher support is not necessarily a serious issue if you had disabled the SSL v2 and SSL v3 protocols in your browser configuration settings or forcing client/servers to communicate only using TLS 1.2 and TLS 1.1 protocol always. Also google engineers proposed TLS GREASE (Generate Random Extensions and Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. GREASE is specifically looking to find servers that don’t deal well with unexpected values. For example, when establishing a connection, the client provides the server with a list of capabilities it supports – for everything from protocol version to cipher suites. If the server does not recognize one of the values the client provides, it should be able to ignore it and successfully start a connection with the best available options.
Authored By - Venkatesh G
TCS Enterprise Security and Risk Management
Rate this article: 
Average: 1 (955 votes)
Article category: