Protect Your Assets
Showing results for 
Search instead for 
Do you mean 

SSLv3/TLS Renegotiation Stream Injection

matt wood ‎11-16-2009 11:00 AM - edited ‎09-29-2015 09:59 AM

Recently, Thursday 11/5/09, a few folks over on the IETF mailing list went public with a limited Man-in-the-Middle attack on SSLv3 and TLS. There has been quite a bit of press coverage on this issue's severity. However, the way this attack can be used is proving to be more dangerous in specific contexts than at first thought. This vulnerability affects almost every SSL/TLS implementation: IIS (5|6|7), Apache mod_ssl < 2.2.14, OpenSSL < 0.9.8l, GnuTLS < 2.8.5, Mozilla NSS < 3.12.4, and certainly more. Any products using these libraries as their underlying secure transport layer are also vulnerable to this content injection vulnerability. This vulnerability has been assigned CVE-2009-3555 by Mitre and I'm sure they will continue to update their listing with newly affected packages as they are found.


At a high level, this is not a true Man-in-the-Middle attack. An attacker leveraging this vulnerability can only inject data and is unable to read client traffic or server responses. While this is not an entire compromise, there are novel attacks that can be performed in the context of HTTP and SSLv3/TLS. In order for SSLv3/TLS to support long running sessions, at a protocol level, encryption keys must be changed to ensure cryptographic security. However, the real problem manifests within the communication between an application and the SSLv3/TLS library the server is using. Since HTTP requests cannot be processed until they are complete, web servers keep the request in a buffer until it is complete. When the SSLv3/TLS libraries receive new packets they are immediately forwarded to the web server once decrypted at a protocol level. The issue here lies within that caching behavior; before completing the HTTP request, the client initiates a key renegotiation then sending new keys. Except these new keys could have been from the client connecting to the man-in-the-middle and just simply forwarded by the attacker. This is especially malicious because the client will never know he has been man-in-the-middled as the communication between her and the server appears completely normal. Unfortunately, prior to this vulnerability disclosure SSLv3/TLS enabled web servers do NOT flush the data buffers before the renegotiation. Thus an attacker can leverage this optimization/feature/whatever to inject data into the beginning of the conversation between the unexpecting client and the web server.


Given an attacker can get traffic routed through him (this is easy in a WiFi environment or with arp poisoning) the attacker can effectively transparently proxy a client's request through him. Now using this vulnerability, any HTTPS connection through him can have arbitrary data from the attacker prepended to anything the client sends. This is especially bad for HTTP requests.


These theoretical attacks all require some type of renegotiation to occur. Luckily, for an attacker, there are simple ways that can be utilized. The possible ways renegotation can be forced are:

    • Any server that allows client renegotiation.


    • Servers with public access to a subset of folders, and a set of secure folders requiring a client certificate.


    • Servers that renegotiate for any reason.

Of course the libraries have quickly identified and fixed some of the issues that cause this vulnerability. OpenSSL has disabled renegotiation for SSLv3 and TLS in a patch. GnuTLS has implemented some of the drafted larger fixes for TLS specifically. Apache has fixed the some of the issues at the application layer associated with the prepended attacks, but this still requires patches of openssl to completely solve all the certificate attacks (doesn't prevent from server initiated renegotiation).


WebInspect will now also test any SSL web servers for this vulnerability with Check ID 10942. Simply SmartUpdate to receive the latest checks.

0 Kudos
About the Author

matt wood

on ‎11-16-2009 04:44 PM

Twitter usernames & passwords were gathered via this bug in a real-world exploit.

on ‎01-05-2010 04:11 PM

Do you know how is WebInspect checking for this vulnerabilty in Check ID 10942?

on ‎01-07-2010 09:23 PM

it does a renegotiation  of the SSL stream as if it were a man in the middle attack and then flags if it was successful.

more information can be found at:



on ‎12-16-2010 09:32 PM

What if the OpenSSL server is running 0.9.8m or later where the server enables renogotiation, but by default, it does it in a secure manner.  IOW, OpenSSL fixed the issue and enables renegotiation - will WebInspect flag this as a vulnerability even though it's now considered 'secure'?

27 Feb - 2 March 2017
Barcelona | Fira Gran Via
Mobile World Congress 2017
Hewlett Packard Enterprise at Mobile World Congress 2017, Barcelona | Fira Gran Via Location: Hall 3, Booth 3E11
Read more
Each Month in 2017
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all