This question already has an answer here:

In SSL, the client generates a pre-master key from random data from itself and also the server. It then encrypts this with the server's public key, sends it to the server and then both client and server generate a master key from this.

Why not have the client generate the master key and send that to the server?

My initial guess is to prevent the master secret from ever going over the wire in any shape or form. But I don't see how that is any safer than having the pre-master key sent over the wire if a Man in the Middle has observed the entire handshake (and thus knows the cipher used, and the random data sent by both client and server).

marked as duplicate by TildalWave, Eric G, Xander, Adi, Steve Mar 30 '14 at 20:44

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

The point of the pre-master key is to have a uniform format for the master key (e.g. this helps sharing session parameters between multiple front-ends). SSL is generic: it supports several kinds of key exchange algorithms, in particular RSA asymmetric encryption, and various Diffie-Hellman variants. All these methods do not yield "shared secret" of the same size and format. Notably, with DH, you get a group element, in whatever group you are working, which can be an elliptic curve or something else; the shared secret is, as a binary string, somewhat biased, and is not chosen by the client.

Defining that the key exchange mechanism yields a pre-master secret (with characteristics derived from the actual key exchange mechanism), to be hashed into a master secret, thus allows for a better modularity.

Not the answer you're looking for? Browse other questions tagged or ask your own question.