The renegotiation process of the SSL encryption is vulnerable. It allows two negotiations to be handled by different parties. This leaves your data vulnerable to Man-In-The-Middle attacks.
Security Assessment
CVSS Vector: AV:N/AC:M/AU:N/C:N/I:P/A:P
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 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 web server 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 Linux
How 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.
How to Test for Secure Renegotiation
Do you know if your system or a specific application is vulnerable to the threat of 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.