Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
1  
I suggest linking to the original source that you are referring to. Are you talking about RFC 5746? –  D.W. Apr 24 '12 at 22:58
    
@D.W. Yes. RFC5746 –  Jim Apr 26 '12 at 6:06

3 Answers 3

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.

share|improve this answer
    
I'd use POST for these examples, since for well designed websites GET should not trigger actions. This attack technique obviously allows one to forge POST request just as easily as GET requests. –  CodesInChaos Apr 25 '12 at 10:11
1  
@CodeInChaos, agreed (just taking the example from EKR here), but POST is actually a bit more difficult to forge here, since it's hard to get the legitimate cookie in the request and the attacker's entity (considering the order). That's why this attack has limited impact in practice. –  Bruno Apr 25 '12 at 10:52

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:

share|improve this answer
    
Good explanation. I've always thought more awareness by the application layer that a re-negotiation was happening would also be better (in addition to these fixes). –  Bruno Apr 24 '12 at 23:38
    
"the client can supply a client certificate, even if he didn't supply one initially" What's interesting here is that the client certificate will be sent encrypted if it happens during reneg, but not if it happens in the original exchange. Unfortunately the fact that reneg happens is still visible to a listener. –  CodesInChaos Apr 25 '12 at 10:19
    
@D.W:If parts of a server's site require client authentication it is possible that renegotiation will happen. In this case though the attacker's request is send to a URL that will be "redirected" to the site that requires the client certificate. But in this flow there are no application data yet. The application data will start after the client has been authenticated. So in this flow I can not understand how the attacker can exploit the renegotiation, since before the renegotiation (point which the server does not know if the request will end up with cert-auth) there are no application data. –  Jim Apr 26 '12 at 6:58
    
@Jim, in this attack, the attacker establishes the first SSL connection to the server, so the attacker can choose when renegotiation will happen. The attacker might send some data, then trigger renegotiation at any point. (You're saying this is not the way things normally would work when an honest client connects, and that may well be, but here it is the attacker who is connecting, not the honest client. When the attacker has originated the SSL connection, the attacker can initiate renegotiation at times when you may not be expecting it to happen.) –  D.W. Apr 26 '12 at 15:02

(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.

share|improve this answer
1  
Any source for this? I don't believe it works. –  CodesInChaos Apr 24 '12 at 21:31
1  
The MITM doesn't control everything: it can only prefix the application data. –  Bruno Apr 24 '12 at 22:42
    
Right, the MITM can't decrypt, only inject. I've edited my answer for that point and take the -1, hoping that my edited answer is now correct, if not as well laid out as the others. –  ixe013 Apr 25 '12 at 14:10

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.