Not clear on ssl renegotiation vulnerabilty

Question

When we read about TLS Renegotiation vulnerability, does it mean that a server is not supposed to ever accept renegotiation during a secure connection?
I thought that by renegotiation security is enhanced. No?

Answer 1

The problem is not in doing a renegotiation; it is in believing in security characteristics that the renegotiation does not provide.

Renegotiation is making a new handshake while in the middle of a SSL/TLS connection. This is described in the standard, albeit not in very clear terms, especially when it comes to defining what guarantees renegotiation offer.

Renegotiation is very common when used with client certificates, especially with IIS. Things go like this:

• Server receives a connection request on port 443; it begins a handshake. The server does not ask for a client certificate.
• Once the handshake is completed, the client sends the actual target URL as a HTTP request in the SSL tunnel. Up to that point, the server did not know which page was targeted; he only knew, at best, the intended server name (through the Server Name Indication). Now that the server knows which page is targeted, he knows which "site" (i.e. part of the server, in IIS terminology) is to be used.
• If the specific site requires or at least demands certificate-based client authentication, the server triggers a new handshake, this time with a CertificateRequest message.

The security issue here is a question of layers. Handshake messages appear "under the cover" as administrative out-of-band administrative interactions, around the main "application data" traffic, which is just HTTP. Once the new handshake has been performed, any subsequently sent application data is covered by the authentication umbrella of SSL. However, what of the application data which was sent before the second handshake, in particular the initial HTTP request which decided the server to perform a second handshake, or, crucially, other HTTP requests pipelined after it (but before the new handshake) ?

It so happens that Web servers tended to just assume that whatever authentication was just performed in the second handshake could be "transported" to previous data, retroactively. It so happens that it is not true. That's never clearly said in the SSL/TLS standard, but such authentication only acts in a forward way: no time travel. The important word in the previous paragraph is "subsequently". This allowed an actual attack (see this page for pointers to extensive explanations).

A crucial point for the practical attack is that the second handshake messages are indistinguishable from the handshake messages for a new connection (i.e. a "first handshake"). RFC 5746 describes the patch, which has been implemented in major browsers and servers (which we assume to be up-to-date with security fixes; otherwise, you are in big trouble anyway). This is also what OpenSSL reports as "Secure Renegotiation". Note that the RFC candidly says that:

While this extension mitigates the man-in-the-middle attack described in the overview, it does not resolve all possible problems an application may face if it is unaware of renegotiation.

In other terms, this is a patch to fix a demonstrated issue, but it does not claim to cover all grounds. What renegotiation really offers is still not clearly defined anywhere. If your clients and server support "Secure Renegotiation" then things are fine for now (it prevents all currently known attacks). The whole concept of renegotiation and interleaved handshakes is still sorely in need of a more formal analysis.

Answer 2

During renegotiation an attacker can inject information into the connection. It is described in detail here.