Having SSL Renegotiation enabled is a denial of service attack vector. An SSL Renegotiation Man in the Middle vulnerability was reported in 2009 as CVE-2009-3555. The vulnerability relies on two key issues: having SSL Renegotiation enabled and having a vulnerable SSL Implementation (pre RFC 5746 also known as insecure renegotiation). There is another issue that ONLY requires having SSL Renegotiation enabled (secure or insecure) allowing a Denial of Service which I will present in this post and CVE-2011-1473.
SSL/TLS Renegotiation Man in the Middle
The TLS protocol, and the SSL protocol 3.0 and possibly earlier, as used in Microsoft Internet Information Services (IIS) 7.0, mod_ssl in the Apache HTTP Server 2.2.14 and earlier, OpenSSL before 0.9.8l, GnuTLS 2.8.5 and earlier, Mozilla Network Security Services (NSS) 3.12.4 and earlier, multiple Cisco products, and other products, does not properly associate renegotiation handshakes with an existing connection, which allows man-in-the-middle attackers to insert data into HTTPS sessions, and possibly other types of sessions protected by TLS or SSL, by sending an unauthenticated request that is processed retroactively by a server in a post-renegotiation context, related to a “plaintext injection” attack, aka the “Project Mogul” issue.
This confirms that the Man in the Middle vulnerability exists two key issues must be present:
- SSL Renegotiation enabled (insecure renegotiation)
- A vulnerable SSL Implementation (pre RFC 5746)
This post is not focused on the MiTM issue as this has been documented multiple times by the original finder Marsh Ray and Steve Dispensa on ExtendedSubset.com who also published a POC, Pavel Kankovsky who published the first POC, Arnil Kurmus on SecureGoose, Eric Rescola on EducatedGuessWork, and Tom Cross from ISS.
However, I must mention that the industry continues to identify SSL Renegotiation enabled as a MitM vulnerability when only insecure renegotiation is vulnerable. For example, Nessus has a plugin that identifies SSL/TLS Renegotiation handshakes MiTM Plaintext Data Injection.
The plugin only checks if SSL Renegotiation is enabled. Update: Nessus has updated the plugin to check for secure and insecure renegotiation; only insecure renegotiation is flagged as vulnerable). Kai Engert has confirmed his site checks for RFC 5746 and SSL Renegotiation before reporting a site vulnerable. To verify a site is vulnerable, insecure renegotiation must be disabled. However, a denial of service issue exists when SSL Renegotiation is enabled whether secure or insecure.
SSL/TLS Renegotiation Denial of Service
An SSL/TLS handshake requires at least 10 times ( up to 35x depending on cipher strength) more processing power on the server than on the client. The handshake and negotiation is only performed at the beginning of a secure connection to establish it. When SSL/TLS Renegotiation is enabled on the server, a user is allowed to send a renegotiation request which initiates a new handshake. Since it takes much less resources for a client to perform a handshake, requesting multiple handshakes per second could cause a denial of service on the server side SSL/TLS interface. Therefore, if a malicious user on one host requests multiple renegotiation requests it will exhaust the server’s resources and not allow any other user to establish a connection.
This attack is different than a Distributed Denial of Service (DDOS) as it does not require the volume, or botnet, to exhaust the network connection. Instead it exhausts the server resources from a single host requiring only a single TCP/IP socket. A single server can perform between 150-300 handshakes per second. While a single client can request up to 1000 handshakes per second.
The main issue is that SSL handshakes are more resource intensive on the server side than on the client side. There are other methods of causing denial of service because of this, SSL Renegotiation is simply another attack vector and the most effective at causing a denial of service as it may be done from a single TCP/IP connection. Other methods include:
- Flood of new SSL handshakes – requesting multiple SSL connections
- Flood of precompiled SSL handshake(s) – requesting the server to decrypt data
- Flood of 128 bits – requests the server to decrypt garbage
- Anything that triggers SSL handshake cryptographic logic on server side
There are multiple ways to determine if SSL/TLS Renegotiation is enabled. Nessus has a plugin for this issue, Qualys has a site to test for it, Nasko Oskov has a site, and you can do so manually with OpenSSL (thanks to Ivan Ristic; note you must use a version newer than 0.9.8l for secure renegotiation):
- openssl s_client -connect ip:port
- HEAD / HTTP/1.0
Proof of Concept
The Hackers Choice semi-silently released a proof of concept tool on February 28, 2011 at DC4420 that performs the described denial of service against servers that allow SSL/TLS Renegotiation. I recommend reading the source code before running it and ensure you have permission to run a denial of service attack against the target. To use the tool, I used BackTrack:
- Download: wget http://www.thc.org/thc-ssl-dos/thc-ssl-dos-1.4.tar.gz
- Extract: tar -zvxf thc-ssl-1.4.tar.gz
- View files and source: cd thc-ssl-dos/src
- Edit the source: vim thc-ssl-dos.c
- I recommend adding a 1 instead of 0 to the two flags required to run the program. You may also edit the max amount of connections.
- Configure: cd .. Then: ./configure
- Install: make all install
- Run: cd src Then: ./thc-ssl-dos ip port
- Options include: -l x where x is the number of connections, the default is 400.
Radware has confirmed that these attacks have been seen in the wild for over a year now.
A preventive measure to this issue would be to disable SSL/TLS Renegotiation. The vendor of your specific SSL Implementation should have documentation on disabling this “feature”; note that the issue is with the SSL Implementation not the protocol itself.
- All versions of OpenSSL prior to 0.9.8l are vulnerable. The latest version of Apache with latest version of OpenSSL does not appear to have SSL Renegotiation enabled by default.
- Microsoft IIS 6 and higher are not vulnerable by default. MS10-049 has more information if enabled.
- F5 has an iRule for this issue which doesn’t allow more than 5 renegotiations per 60 second.
These are some suggestions for mitigating an SSL Denial of Service attack:
- Most IDS and IPS vendors have signatures to detect multiple SSL Renegotiation requests from the same source in a given time frame. Contact your particular vendor for this request.
- Rate limiting on new incoming TLS connections AND renegotiations per source IP; most implementations only perform rate-limiting on new connections if at all.
- SSL Accelerator, although adding multiple hosts to your attack would render it useless as well.
- Anti-DoS equipment, some ,dedicated equipment can handle over 10K new SSL connections per second, which can be quite effective.
I have calculated this as a High risk issue using CVSS v2: 7.8 (AV:N/AC:L/Au:N/C:N/I:N/A:C)
Peer Review and Feedback
I would like to thank all that provided feedback and peer review for this issue: Ron Gula and Tenable, Steve Dispensa, Nasko Oskov, Marsh Ray, Peter Gutmann, Eric Rescorla, Kai Engert, Alex Kirk and Sourcefire, Dan Kaminsky, Yuri Gushin and Alex Behar from ECL Labs and all in the IETF TLS mailing list.
Please leave a comment or use the contact form to provide feedback or request denial of service proof of concept testing on your site.
OpenSSL has acknowledged this issue and has posted an advisory on SecurityFocus.