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?

1 Answer 1


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.


You must log in to answer this question.

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