Skip to main content

Prevent SSL renegotiation attacks

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​

Security_Assessment_ SecureSSLRenegotiation

CVSS vector: AV:N/AC:M/AU:N/C:N/I:P/A:P

Vulnerability information​

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 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.

Prevent attacks​

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 do not 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

Disable 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 is crucial to set only secure renegotiation and define the number of possible SSL handshakes.

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 DAST Essentials for free.

Last updated on