During the asymmetric phase the parties will use an asymmetric algorithm known as RSA. The parties will make use of the server keys (see previous post). The Client has a copy of the public one (as possibly everyone else) for encryption, but it is expected that only the Server knows the private key for decryption. The Server is the one who choose the cipher to use.

The Client uses the server public key and with an already negotiated asymmetric cipher encrypt the pre-master secret, which is another random number, and sends that to the Server. Be aware that the Client don't wait for the Server to receive the encrypted message in order to go to the next step.

Now the Server uses the private key to decrypt the Client's pre-master secret. The pre-master secret was safely passed through the public domain and now they both finally share their first secret. The asymmetric phase is completed.

Inputs for the function will be the client random and the server random (both shared unencrypted during the hello step), and the pre-master secret (which is ideally only known to the Server and the Client). The fact that one of the inputs is a secret to everyone else (ie. the pre-master) makes the output of the function unkown to others.

The processing function is usually a Pseudo Random Function (PRF), which is a procedure that will result in the same pseudo-random value on the side of the Client as well as the Server, as long as they both apply the same procedure and use the same inputs. The most important here is that no-one will be able to infer the exact values of the inputs reversibly by obtaining the output of the function, guaranting certain level of safety.

By using the same procedures and parameters the Server and the Client create identical master secrets.

Why not simply using the pre-master secret instead? Let's use our early example to understand why. Try to imagine the pre-master as a random mix of hundreds of characters from several different alphabets. But to encrypt and decrypt a message written with a Latin alphabet of only 26 characters, we don't need them all. A random selection of a fixed amount (in this case 26) of those characters would be our master secret. This is more or less the idea that justify the construction of the master secret from a pre-master.

The master secret and the randoms will be used to create the session keys using a similar procedure as for the creation of the master secret. Both parties produce more than one key in a single key block that is eventually "sliced" up to the right sizes. The resulting session keys would fit the symmetric cipher previously negotiated between the parties. The keys are ready: we can move to the next phase.

Both the Client and the Server will use an agreed symmetric cipher function now with a similar key on each side.

The reason why several session keys instead of one is because in practice there are more than one type of communication going through more than one communication channel during a single session. Encrypting each type of communication for each channel using different keys adds a higher level of security.

Even before the Server gets the encrypted pre-master the Client might already have the session keys, so it is the Client the first to test the resulting procedure. The Client encrypts a message ("finished") with test data which would revail if the handshake was tampered or not, and sends it to the Server...

If, after receiving and decrypting the ciphertext the Client message was as expected, the Server will respond to the Client with a similar message...

If the Client gets the message from the Server as expected, then the handshake is finished.