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?