A message authorization code is used in TLS to prevent man-in-the-middle-attacks that involve tampering with the contents of the packet in-flight. However, there is one specific attack which I don't see covered.
At one stage of the TLS handshake, the client sends the server a private randomly generated proposed symmetric key which has been encrypted with the server's public key. A man the middle cannot decrypt that value and learn the value of the symmetric key because it does not possess the private key. However, it can swap the contents of the message with its own private symmetric key, and send that message to the server instead.
The message authorization code (MAC) can supposedly prevent this from happening:
If we agree on a key and hashing cipher, you can verify that my message comes from me, and I can verify that your message comes from you.
An attacker can modify the message but does not know the key. He cannot compute the correct MAC, and you will know the message is not authentic.
What if an attacker generates their own symmetric key, encrypting that value with the public key, setting that value as the data payload, setting the MAC to the corresponding value for the new proposed symmetric key, and sends that to the server?
If my understanding is correct, the server will decrypt the message payload using its private key, verify message integrity using the MAC, set that to be the shared secret symmetric key value, and respond to the "client" (really, the attacker) with the data payload "Finished" encrypted with that key. In essence, the server now has a shared secret with the attacker, who it thinks is the client.
Not knowing the original secret symmetric key, the man in the middle cannot actually forward the server response to the client. Nevertheless, at this point the man in the middle can make requests to the server, whilst masquerading as the client.
Does TLS actually protect against this somehow?