6

I've read RFC 5746 on the TLS secure renegotiation extension. However, I don't understand how it fixes the problem.

Client and server are required to include the verify_data from the previous handshake in the ClientHello and ServerHello messages. The fix protects against an attacker who is an active MITM. Couldn't this attacker just include his verify_data in the ClientHello he intercepts from the client (remember, this is all unsigned, key exchange is going on) and strip the verify_data from the ServerHello the server responds with? This way, the server will think secure renegotiation is going on, while the client will see an empty renegotiated_connection field which corresponds with the fact it's starting a new connection.

My reasoning must be wrong, can someone point it out?

Jonas
  • 5,063
  • 7
  • 32
  • 35
chris
  • 3,000
  • 14
  • 22

1 Answers1

10

In a TLS handshake, the "Finished" messages contain a value which is a hash of all the handshake messages exchanged so far (for this handshake). If the attacker alters the ClientHello then the hash will not match: when the second handshake completes (the first and only handshake in the view of the client, the second handshake from the point of view of the server), the client sends a 'Finished' message that the attacker cannot modify (it is encrypted & MACed with the newly negotiated key), and that message contains a hash computer over, among other things, the ClientHello that the client sent. If the server saw a distinct ClientHello (one without the renegotiation extension), then he will compute a distinct hash, the "Finished" contents will not match, and the connection will be aborted.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949