An SSL/TLS handshake is a negotiation between two parties on a network – such as a browser and web server – to establish the details of their connection.
The main purpose of an SSL handshake is to provide privacy and data integrity for communication between a server and a client.
During a TLS handshake, the two communicating sides exchange messages to acknowledge each other, verify each other, establish the encryption algorithms they will use, and agree on session keys.
Purpose of SSL/TLS Handshake
- Agree on the version of the protocol to use.
- Select cryptographic algorithms.
- Authenticate each other by exchanging and validating digital certificates.
- Use asymmetric encryption techniques to generate a shared secret key, which avoids the key distribution problem. SSL or TLS then uses the shared key for the symmetric encryption of messages, which is faster than asymmetric encryption.
Overall Steps between SSL/TLS Handshake
-
The client sends a request to the server for a secure session. The server responds by sending its X.509 digital certificate to the client.
-
The client receives the server’s X.509 digital certificate.
-
The client authenticates the server, using a list of known certificate authorities.
-
The client generates a random symmetric key and encrypts it using server’s public key.
-
The client and server now both know the symmetric key and can use the SSL encryption process to encrypt and decrypt the information contained in the client request and the server response.
How SSL/TLS Handshake works?
- The client sends a “client hello” message. This includes the client’s SSL version number, cipher settings, session-specific data and other information that the server needs to communicate with the client using SSL.
- The server responds with a “server hello” message. This includes the server’s SSL version number, cipher settings, session-specific data, an SSL certificate with a public key and other information that the client needs to communicate with the server over SSL.
- The client verifies the server’s SSL certificate from CA (Certificate Authority) and authenticates the server. If the authentication fails, then the client refuses the SSL connection and throws an exception. If the authentication succeeds, then proceed to step 4.
- The client creates a session key, encrypts it with the server’s public key and sends it to the server. If the server has requested client authentication (mostly in server to server communication), then the client sends his own certificate to the server.
The server decrypts the session key with its private key and sends the acknowledgement to the client encrypted with the session key.
At the end of the SSL handshake, both the client and the server have a valid session key which they will use to encrypt or decrypt actual data. The public key and the private key will not be used any more after this.
Understanding Shared Session Key
The client and the server now use a shared session key to encrypt and decrypt actual data and transfer it. This is done using the same session key at both ends and so, it is a symmetric cryptography. The actual SSL data transfer uses symmetric cryptography because it is easy and takes less cpu consumption compared with the asymmetric cryptography.
Understanding one-way SSL and two-way SSL
There are two types of SSL handshakes described as one-way SSL and two-way SSL (Mutual SSL).
- One-way SSL – only the client validates the identity of the server. when we browse an HTTPS website, one-way SSL is being used where only our browser (client) validates the identity of the website (server).
- Two-way SSL – both server and client validate the identity of each other. Two-way SSL is mostly used in server to server communication where both parties need to validate the identity of each other.