A number of Internet connections require SSL renegotiation, a Secure Sockets Layer/Transport Layer Security process that allows the changing of the details of a handshake after a connection is made with the server.
Renegotiation is required when no client-server authentication is initially required while making an SSL connection but is required later. Thus instead of dropping and creating a new SSL connection, renegotiation adds authentication details to the current connection.
Renegotiation is used by ecommerce apps, cloud providers, and others. There are four types:
- Client-initiated secure renegotiation
- Client-initiated insecure renegotiation
- Server-initiated secure renegotiation
- Server-initiated insecure renegotiation
Renegotiation can open the door to attacks. There are two primary worries:
- CVE-2009-3555: This vulnerability allows a “man-in-the-middle” attacker to inject data into an HTTPS session and execute requests on behalf of the victim. Refer to CVE-2009-3555 for more details.
- Denial of Service (DoS): Establishing a secure SSL connection requires more processing power on the server, around 15 times, than on the client. An attacker can exploit this processing-power property along with renegotiation to trigger hundreds of handshakes in the same TCP connection; an assault can bring down a 30Gb-link server using only a laptop and DSL connection.
The THC group demonstrated the DoS attack and released a tool, THC-SSL-DoS, as a proof of concept. An SSL DoS attack can be carried out without SSL renegotiation by simply establishing a new TCP connection for every new handshake. SSL renegotiation makes it very easy to carry out this DoS attack.
We can take several steps to mitigate the threat of renegotiation attacks.
- Renegotiation is not required by the majority of sites. Disable SSL renegotiation support on the server.
- If disabling renegotiation is not possible due to business needs such as ecommerce, then allow only secure renegotiation and limit the number of SSL handshakes, or upgrade server resources by adding products like an SSL accelerator. Do not support insecure renegotiation.
- If disabling renegotiation is not possible due to a legacy server not having the option to disable renegotiation, then limit the number of SSL handshakes, or upgrade server resources by adding products like an SSL accelerator.
- Information on how to limit the number of SSL handshakes can be found here.
- Amazon Web Services Elastic Load Balancing does not support disabling client-initiated renegotiation. As an alternative solution, you can use port 443 as TCP rather than HTTPS so that all requests are passed to the server and also disable renegotiation on the server.
Testing mitigation
Connect using OpenSSL with the following command and press “R” once the connection is successfully established:
openssl s_client -connect <hostname/IP>:<port>
……..
R
If you want to see verbose output, then use following command and press “R”:
openssl s_client -connect <hostname/IP>:<port> -msg
………..
R
The preceding method tests secure and insecure client-initiated renegotiations. Server-attempted secure and insecure renegotiations are also possible, but those requests need to be issued from server.
OpenSSL Version 0.9.8k or earlier attempts by default an insecure renegotiation, while Version 0.9.8m or later attempts by default a secure renegotiation. (With Version 0.9.8l, the renegotiation request is blocked on the server and the client times out.)
If renegotiation is not supported, test using OpenSSL Version 0.9.8m or later. The output will be an error something like this:
If testing for a secure renegotiation, use Version 0.9.8m or later and observe the results:
If testing for an insecure renegotiation, use Version 0.9.8k or earlier and observe the results:
Eliminating a false positive
Don’t depend upon the OpenSSL statement “Secure Renegotiation IS supported.” This means only that OpenSSL version you are using supports secure renegotiation. It doesn’t ensure that server supports secure renegotiation. To test this, press “R,” as detailed earlier, and observe the output to confirm whether the server supports secure renegotiation. The following screenshot shows that renegotiation was not supported by the server even though we see the message “Secure Renegotiation IS supported.”
Depending upon your OpenSSL version you might see different results from the same server. Consider a scenario in which secure renegotiation is supported by the server. When tested with OpenSSL Version 0.9.8h, for example, renegotiation fails because that version by default attempts an insecure renegotiation.
When tested with OpenSSL Version 1.0.1, renegotiation was successful because Versions 0.9.8m and later by default attempt secure renegotiation.
Be mindful of your OpenSSL version while testing for SSL renegotiation. And remember, OpenSSL never releases Windows-based binaries. Any Windows apps you see are third-party binaries. The official OpenSSL runs only on Linux; you should test only from a Linux machine.
References
- https://vincent.bernat.im/en/blog/2011-ssl-dos-mitigation.html
- https://www.thc.org/thc-ssl-dos/
- https://blog.ivanristic.com/2009/12/testing-for-ssl-renegotiation.html
The post Tips for Securing SSL Renegotiation appeared first on McAfee.