Many internet connections work with Secure Sockets Layer (SSL) renegotiation — including eCommerce apps, cloud providers, and many more. This is a Secure Sockets Layer/ Transport Layer Security (TLS) process that enables the amendment of handshake negotiation details once a connection with the server has already been established.
The concept of renegotiation in security protocols used all over the digital space is simple but effective. Instead of canceling a connection and starting another one anew, the session renegotiation provides authentication data to the existing connection beyond the initial negotiation that was set up.
For example, a customer is browsing an online shop without logging in. However, they decide to make a purchase, so they have to enter their authentication credentials and access their profile on the eCommerce platform. This is a practical example of the necessity for an SSL renegotiation request instead of starting a connection from scratch.
The SSL/TLS renegotiation vulnerability is a potential cyber threat in cases when a client can initiate a renegotiation process. An attacker can abuse this situation by making the server unavailable with a Denial of Service attack or can execute a Man-in-the-Middle injection attack into the HTTPS sessions.
Let’s dive into the security issue details around the SSL renegotiation process.
What Is the SSL Renegotiation Vulnerability?
The negotiation process of the SSL encryption uses significantly more resources on the server than on the client. Therefore, if the client can initiate the renegotiation process, an attacker can render the server unavailable with a Denial of Service attack.
The SSL renegotiation flaw can affect different types of systems. It is essentially caused by a vulnerability in the client-initiated renegotiation of SSL/TLS for existing server connections.
Some of the symptoms of renegotiation issues include:
- It fails in the case of a virtual server processing SSL connections
- There are BIG-IP system error messages logged about SSL handshake/renegotiation
- The virtual server rejecting renegotiation attempts is logged in the SSL statistics
In a nutshell, the SSL communication — or handshake process — entails exchanging messages between the server and the client. They define the settings of the encrypted communication, including enabled cipher suites, protocol version, renegotiation security, and others.
The SSL handshake contains components like ClientHello, ServerHello, server’s certificate, ServerHelloDone, ClientKeyExchange, ChangeCipherSpec, Finished, Renegotiated SSL sessions, and Renegotiation settings.
The last two components relate to the SSL renegotiation. The initial handshake process can be renegotiated with different cryptographic parameters if necessary. The other options for a renegotiation setting include how the renegotiation requests are processed, period (renegotiation after a certain time period), size (after a certain amount of data), and max record delay (number of delayed records), among others.
How Does This Vulnerability Work?
Four different kinds of negotiation processes can occur if initial connections have already been made, and it’s preferable not to drop them.
The renegotiation can be client-initiated, which can be secure or insecure. The most problematic is the client-initiated insecure renegotiation. The safer option is that the renegotiation is server-initiated, which can be secure or insecure again, as the client-side renegotiation carries inherent risks.
There are two potential cyberattack scenarios related to the SSL/TLS renegotiation:
- A Man-in-the-Middle attack (injection vulnerability) that inserts malicious data (plain text can be inserted as a prefix to a TLS connection) into HTTPS sessions through an unauthenticated request (CVE-2009-3555). By doing this, the attacker may run commands with the credentials of an already authorized user and even gather other users’ credentials.
- A Denial of Service condition starts hundreds of handshakes from clients for the same TCP connection, abusing the fact that a secure SSL connection is 15 times more power-heavier for servers than for clients.
Discovery of the Vulnerability
The THC group proved the Denial of Service attack in 2009. The group created a tool called THC-SSL-DoS to demonstrate the idea behind the vulnerability. Even without SSL renegotiation, such a DoS attack can be executed by setting up new TCP connection attempts per each handshake. Still, the renegotiation further enables the ease of making the attack.
Impact
Since SSL renegotiation is a commonly used practice, the vulnerability related to client-initiated renegotiation should not be underestimated. It can affect different types of businesses and organizations. That’s why the calculated severity of the security flaw is significant.
At the same time, since most systems don’t allow client-initiated renegotiation by default, it should not be a big issue with current users — unless insecure renegotiation or client-initiated ones are permitted.
SSL Renegotiation Security Assessment
CVSS Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
How to Prevent Insecure Server- and Client-Initiated SSL Renegotiation
As illustrated in the previous sections, insecure client-initiated SSL renegotiation poses a severe threat to your systems. The problem has been fixed in consecutive web server versions, such as the latest versions of Apache and Nginx. They don’t allow client-initiated SSL renegotiation.
This means that you always have to ensure that your webserver is up-to-date. By doing this, you can provide the best current protection.
To double-check that, you have to run:
apt-get update; apt-get upgrade # Debian / Ubuntu
yum update # RHeL / CentOS
pacman -Syu # Arch LinuxHow to Turn Off Renegotiation
You must manually disable these configuration options if your web server does not prevent client-initiated SSL renegotiation by default. The guiding principle is that only the server should be allowed to initiate a renegotiation of the SSL/TLS connection.
In some cases, disabling a client renegotiation attempt may not be possible. Then it’s crucial to set only secure renegotiation and define the number of possible SSL handshakes.
Prevention Guide
Learn how to detect and prevent different kinds of SSL/TLS vulnerabilities.
How to Test for Secure Renegotiation
Do you know if your system or a specific application is vulnerable to the threat of the client-initiated SSL renegotiation due to unpatched clients or other issues? You can run a non-invasive scan with Crashtest Security’s Vulnerability Testing Software for free. And if you have any questions about SSL/TLS implementation or have any challenges, we’ll be happy to provide solutions to your specific case.
