SSL Handshaking (Part-2 For Beginners)

Welcome again on the second part of SSL Overview :)
You know the Secure Sockets Layer (SSL) protocol uses a combination of public-key and symmetric-key encryption. Now, Symmetric-key encryption is much faster than public-key encryption; however, public-key encryption provides  you better authentication techniques. SSL session always starts with an exchange of messages called the SSL handshake. More interesting part is that the handshake allows the server to authenticate itself to the client by using public-key techniques, and similarly allows the client and the server to cooperate in the making of symmetric keys used for rapid encryption, decryption during the session that follows. Optionally, this handshake also allows the client to authenticate itself to the server. So here are the steps:

Step 1: Firstly, The client sends the server the client’s SSL version number, cipher settings, some randomly generated data, and other information the server needs to communicate with the client using SSL.

Step 2: Similarly, The server sends the client the server’s SSL version number, cipher settings, randomly generated data, and other information the client needs to communicate with the server over SSL. 

Step 3: After then , the client can use some of the information( which is sent by the server) to authenticate the server. If the server cannot be authenticated, the user is warned of the authentication problem and informed that an encrypted and authenticated connection cannot be established. On the other hand, if the server can be successfully authenticated, the client goes on to Step 4.

Step 4: This step is interesting. Now using all data generated in the handshake so far, the client, with the cooperation of the server, depending on the cipher being used, creates one pre-master secret for the session, by encrypting it with the server’s public key, obtained from the server’s certificate, as sent in Step 2, and sends the encrypted pre-master secret to the server, see the Picture below

Step 5: Now, if the server has requested client authentication the client also signs another piece of data that is unique to this handshake and known by both the client and server. Here the client sends both the signed data and the client’s own certificate(the certificate using by Client) to the server along with the encrypted pre-master secret.

Step 6: Now, two cases happens:

• Case 1: If the server has requested client authentication and the server attempts to authenticate the client and the client can be successfully authenticated, the server uses its private-key to decrypt the pre-master secret, then performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the Server master secret.
• Case 2 : if  the client cannot be authenticated, the session is terminated.

Step 7: So far so good. Now both the client and the server use the master secret to generate the session keys, which are symmetric-keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity-- that is, to detect changes in the data between the time it was sent and the time it is received over the SSL connection.

Step 8: The client sends a message to the server informing it that all theirs future messages from the client are encrypted with this session key. Then it sends a separate (encrypted) message indicating that the client portion of the handshake is finished.

Step 9: In a similar way, also the server sends a message to the client informing it that future messages from the server are encrypted with the session key. Also it then sends a separate (encrypted) message indicating that the server portion of the handshake is finished.

Step 10: Finally, The SSL handshake is now complete, and the SSL session has begun. Now the client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity. :)

[Thank you for reading][Stay connected]