TLS Renegotiation Indication Extension vulnerability

Question

I am trying to understand the TLS Renegotiation Indication Extension from the RFC. I can understand that it is related to the fact that the renegotiation is sent under the encrypted stream, but I cannot undertand the idea and the exploit.
Could anyone please explain it to me in layman's terms so as to be able to understand this and read the RFC?

Answer 1

Marsh Ray's blog seems to be down at the minute, but you can read more on Eric Rescorla's blog (I'm using the same example application data here) or in this PDF (archive.org copy).

• The genuine client sends a Client Hello (GenCH) to the server, but this is intercepted by the MITM.

• The MITM keeps hold of it and starts its own handshake by sending a a Client Hello (MitmCH) to the server too. It completes the handshake normally and sends some application data. For example:

  GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 
  X-Ignore-This:
  

• The MITM now forwards the initial Client Hello (GenCH) to the server.

  As far as the client is concerned, this is not a re-negotiation, but the initial negotiation. It can't tell the difference. The handshake completes and it sends its own request:

  GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 
  Cookie: victimscookie
  

• As far as the server is concerned, receiving a second Client Hello (GenCH) is just a re-negotiation (which either party was able to initiate at any point in time) following the initial handshake initiated with Client Hello (MitmCH). The application layer is treated as continuous. This is what the server sees:

  GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 
  X-Ignore-This: GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 
  Cookie: victimscookie
  

This way, the attacker is able to alter the request line (and thus query parameters) and insert its own headers, while keeping the cookies of the genuine client. The MITM doesn't get to see or alter what the client sends, but it's able to add content before, which is treated as part of the same request on the application layer.

Answer 2

Overview. This is referring to a design weakness associated with renegotiation in SSL that was discovered a few years ago. The extension is designed to close the vulnerability.

Background. SSL allows clients who have an established SSL session with a server to request renegotiation of the session parameters: e.g., the ciphersuite, and other security parameters. Renegotiation basically creates a new SSL session, but is potentially more efficient than creating a whole new SSL connection from scratch. Most crucially, during the renegotiated session, the client can supply a client certificate, even if he didn't supply one initially.

So, if the client initiates renegotiation, we can divide the timeline of the SSL connection into two phases: the pre-renegotiation stuff, and the post-renegotiation stuff.

Prerequisites to attack. The server is only vulnerable to this attack under certain conditions. For a simple example, suppose that the server application is coded in such a way that it checks for a client cert in the renegotiated session, and if it finds one, it treats the entire SSL connection as trusted as coming from that client -- including the stuff that was sent over the SSL connection before renegotiation. On the surface, this seems like a pretty dubious thing for a server application to do, but let's say our server application is coded to do this: to treat the whole connection as authenticated, even if the client only provided any authentication during the post-renegotiation phase. Also, let's assume that the client is going to connect to the server and authenticate to the server with a client cert.

Attack. If these prerequisites are fulfilled, then the renegotiation attack is a man-in-the-middle (MITM) attack. The attack is going to fool the server about the origin of some bytes sent by the attacker: the server is going to get fooled into thinking they came from the client, when actually they came from the attacker.

The attack starts by having the attacker open a SSL connection to the server and sends some stuff to the server (the attacker is going to try to fool the server into thinking those bytes came from the client). Now, at some point the client tries to connect to the server, but as this is a MITM attack, the attacker intercepts it. The attacker initiates renegotiation over the connection he has with the server. During renegotiation, the attacker relays stuff from the client and server back and forth to each other, without modifying the messages. The server thinks it is renegotiating a session over an existing connection; the client thinks it is opening a new connection and new session entirely; but neither detects this inconsistency in their views. During this, the client authenticates using its client cert.

At the end of the attack, let's look at what happens. The renegotiation succeeded. The server successfully verified the client's identity, and knows the client's identity corresponds to the client cert. The client thinks it has completed a successful SSL connection, and has no clue anything is amiss. The server sees a SSL connection that underwent a successful renegotiation, with the post-renegotiation part authenticated by the client's cert.

Now if the server makes the mistake of treating the entire SSL connection as authenticated by the client cert (as we assumed in the prerequisites above), then the server will make the mistake of thinking that the bytes that were sent during the pre-renegotiation phase were sent by the honest client. But in fact those bytes were sent and controlled by the attacker. So the attacker has fooled the server about the source of those messages -- a serious failure of authentication.

As Eric Rescorla says, "Obviously this isn't good, but it's not the end of the world."

Interpretation. At this point we could have a debate about who is to blame. Is the fault of the protocol, for allowing the client and server to end up in a situation where they have a mismatched view of events? Maybe. Or maybe we should say this is the fault of the server, for doing something so stupid as to treat pre-renegotiation bytes as authenticated by an authentication protocol that happened during the renegotiation process, when in fact only the post-renegotiation stuff was actually authenticated by it.

So there are three possible fixes: code your server applications carefully so they don't make this mistake; change the server-side SSL code to refuse all renegotiation requests; or change the protocol so it cannot occur, no matter how the server application is designed. The TLS Renegotiation Indication Extension follows the latter approach. Of course, if your server application doesn't have this problem, then the extension is irrelevant.

The scope of the problem. RFC 5746 has some discussion about situations where this could arise. For instance, beyond client certificates, it could also arise if the server application treats a client as authenticated based upon some secret information (like a HTTPS cookie) that the client sends.

As far as I know, the extension is not widely deployed at this point, but servers can prevent the problem by simply refusing to renegotiate.

More reading. You can read more here:

• Eric Rescorla's excellent description of the problem

• Another excellent description of the problem

• The TLS Renegotiation Attack for the Impatient

• CVE-2009-3555

• What Mozilla is doing about this problem

• To see if your server might be vulnerable, try SSL Labs' automated SSL configuration tester. Their tester will automatically test for this problem.

Answer 3

(This vulnerability assumes you have a man-in-the middle, or MITM. I see it as a way for the MITM to establish a two way SSL connection to a server without the client's private key. How you got a MITM situation is another problem).

Your client sends a Client hello and waits for the server to respond. The client sends some information, including some random value that will be used to establish a session key later on. This will always happen.

The Client Hello is received by the MITM. The MITM uses the same Client Hello to complete the SSL setup on his own. The MITM responds to the Server hello without getting back to the client. Meanwhile, the client is still waiting for the server to respond. Remember that we fooled the client. He thinks the MITM is the server.

So at this point we have:

• A Client waiting for the server to respond with its Server hello
• A MITM that has a full SSL one-way connection to the server

The MITM triggers a SSL renegotiation or the server requests it, probably to achieve two-way SSL. Either way the MITM handles the renegotiation request. It sends the Server Hello the client has been waiting for all along. But now, the MITM controls everything. Whatever the challenge sent by the server, the MITM can replay so that the client will compute the needed values with his (the client's) private key.

Now at this point we have :

• A Client that has a two way SSL session with the MITM, thinking the server responded
• A MITM that can inject data in the communication channel of the client.

By disabling renegotiation, a server will request client authentication in the Server hello message. A MITM will not be able to complete the handshake on its own.