Given a specific SSL/TLS connection, I would like to know what is the proper way to launch a parameter renegotiation, asked from client side.

  1. Are they any requirements from the previous handshake in the parameters established?

  2. What is the exact structure of the first message sent by the client asking for the renegotiation?

  3. What are the next messages exchanged then by the server and the client. If they are different from an usual handshake, in what way?

Thank you in advance for your answers

Additional questions after Thomas Pornin answer :

A. Regarding the RFC 5746

I now understand a bit better how it works, however I still don't catch why renegotiating parameters are an issue when a MITM launches it, according to your link rfc5746#section-1. What interests has a MITM to ask for a renegotiation, since he won't know by any way the secrets exchanged, (in particular the pre-master secret [PMS] sent during the ClientKeyExchanged).

Once the renegotiation is done, the MITM has no way to decrypt the incoming messages sent from the client/server.

I see only 2 possibilities during the renegotiation for exchanging the PMS :

  1. either the MITM provides his certificate to the client, so that the client encrypt the PMS with the MITM certificate. In that case, the client easily detects it, since it's not the certificate he is waiting for ;
  2. either the MITM forwards the server certificate, but in that case the MITM won't have any way to decrypt it, and decrypt the following exchanged messages, since he won't have recovered the PMS.

So where is the security issue allowing some renegotiation by the protocol ?

B. Regarding the structure

You underlined that there was no defined and precise structure given by the RFC. How did OpenSSL team figured this out then? What structure did they choose?

1 Answer 1


See the standard:

The client can also send a ClientHello in response to a HelloRequest or on its own initiative in order to renegotiate the security parameters in an existing connection.

(emphasis is mine)

So the client sends a ClientHello message when it wants to perform a new handshake. This is the very same message that the client would send when first opening the connection, with the same contents (except for the point detailed below). There is no relation with the previous handshake contents, except that the ClientHello, and subsequent messages up to (and including) the next ChangeCipherSpec, are sent within the current cryptographic context. This means that these handshake messages get encrypted and MACed with the algorithms and keys that have been negotiated during the first handshake. When the second handshake reaches the ChangeCipherSpec stage, the newly negotiated algorithms and keys replace those in force up to that point.

The slight difference in the ClientHello and ServerHello for a re-handshake is the Renegotiation Indication Extension: it is a method by which a client may (and should) indicate whether, from its point of view, the handshake is the first one or a new handshake within the context of the current one. The introduction of RFC 5746 explains the issue that RIE purports to fix. The structural issue, though, is that there is no clear definition anywhere of the security properties that a re-handshake are supposed to provide; implementers have resorted to guessing, and the attack for which RFC 5746 is a countermeasure demonstrates that such guessing, as usual, has gone wrong.

(One way to see it is that handshake security goes forward: security guarantees from a TLS handshake are transported into subsequent handshakes. RIE tries to make them go backward too: any authentication resulting from the second handshake would be deemed good enough for data exchange before that second handshake. But RFC 5746 makes no actual promise to that effect and I am not aware of any consistent, coherent and complete analysis of the issue.)

  • 2
    Thank you very much for your clear answer regarding unclear notions ;). This helps me to raise some new points, that I added in the main question by an edit. I hope you will make it as clear as you just did =)
    – Janie
    Jul 21, 2014 at 13:06
  • 1
    The issue explained in the RFC is the following situation: the attacker does a handshake with the server, with no client authentication. The attacker sends a request R. The server notices that the request R requires authentication. Then the attacker forwards within his session what the genuine client believes to be its "first handshake". The server is content with the genuine client authentication. Then the server wrongly assumes that R, sent before that "second handshake", is "authenticated" with the second handshake. The server applies R. Jul 21, 2014 at 13:15
  • 2
    What the TLS standard never said is what exactly you can assume across a second handshake. Here, the server just assumed that authentication (e.g. with certificates) done during the second handshake would somehow applies to pre-second-handshake data. This turned out wrong and an attack was demonstrated. RFC 5746 fixes that attack but fails to define what can now be assumed in that respect, so other similar attacks may still be possible. Jul 21, 2014 at 13:17
  • So if I understand the attack, it's a "one blind shot", since MITM sends R, which will be applied thanks to the client Authentication, but once R is applied, MITM won't have ways to see the returned values (new parameters [not known by the MITM] will be used for this returned data). Am I right there ? If yes, thank you for being that clear. Now, do you know about OpenSSL renegotiation structure approach (B- question) ?
    – Janie
    Jul 21, 2014 at 13:27
  • My use of the word "structural" is about this lack of clear definition. I could have used the word "conceptual" instead. OpenSSL applies RFC 5746. Jul 21, 2014 at 13:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .