SSL/TLS handshake work with Client and Server-side. Let’s find how the SSL/TSL handshake works?
SSL/TLS certificates are digital security certificates, which secure all communications made on the internet with robust encryption. Communication on the internet is made between 2 parties, i.e. browser and server.
Almost 72% of the network traffic is encrypted, which states that all these sites on the internet are secured with SSL/TLS certificates. Their URL starts with HTTPS and includes a padlock in the address bar as well, which depicts that the sites are secured with encryption.
But how does the encryption process work in the backend, and how is the confidential information secured?
In this article, we will discuss how the SSL/TLS connection starts with “Handshake”, and how two parties on the internet encrypt their communications for securing websites.
What is SSL/TLS Handshake?
SSL/TLS handshake is an arbitration made between the browser and the server for establishing the connection details. Since TLS replaced SSL before some time, all SSL handshakes are now defined as TLS handshakes. Both these parties decide on the below steps:
- TLS version which is to be used
- Cryptographic algorithms are to be used
- Cipher suite required to encrypt communication
- Authentication of the server identity by checking the server’s public key and validating the digital signature of the Certificate Authority (CA) issuing SSL certificate
This is a background process, and every time a browser is directed to a secure site; this complex process functions to keep your sensitive data secured.
There are two types of SSL/TLS handshakes.
- One-Way SSL: Only the client (browser) approves the server identity
- Two-Way SSL: Both browsers and servers validate each other’s identity.
In the majority of the cases, two-way SSL is used, and both parties need to validate each other’s identity.
When Does SSL/TLS Handshake Occur?
TLS handshake process is initiated when a user visits an HTTPS site, and the browser starts communicating with the server using HTTPS.
Why is SSL/TLS Handshake Important?
The main motive of the TLS handshake is to ensure data privacy and data integrity by securing communication between browser and server.
SSL/TLS Handshake Explained:
The TLS handshake process is a message process that is exchanged between the client and the server before establishing a secure encrypted connection between the two.
1. Client Hello:
The client (browser) will send a “Client Hello” message stating that it wishes to commence a secure communication. This message also contains the TLS version (TLS 1.0, 1.2, 1.3, etc.) supported by the client, list of cipher suites supported (key exchange algorithm, bulk encryption algorithm, MAC algorithm, a pseudorandom function written in order), the listing of compression methods (optional) and extensions, and the random string to be used for generating cryptographic session keys.
Suppose the server does not support any of the cipher suites mentioned by the client or does not recognize the same, it will send a failure warning alert message and close the connection.
2. Server Hello:
In answer to the “Client Hello” message, the server responds with a “Server Hello” message. This message comprises the TLS version supported by the server, session identifier number, cipher selected from the preferred list of clients, compression algorithm agreed by both parties (optional), and the random string of bytes created by the server which is later used for generating cryptographic keys.
If the server does not accord the cipher choices or the TLS version, it will convey a “Handshake Failure” message and close the connection.
3. Server Certificate:
Apart from the “Server Hello” message, the server also sends a certificate chain, which is the server’s proof of identity, which needs to be authenticated and validated by the client from the client trust store of certificates.
A digital signature of the CA along with the server’s public key is attached in the certificate chain, and the client verifies all the signatures in the certificate till the root CA certificate is gained.
Certificate Validation Process:
- Ensures that the certificate is valid and not expired
- A trusted CA has ensured the issuance of the certificate
- The validity of the digital signature done by CA
- Ensures that the domain name on the server and certificate are matching
4. Server Key Exchange Message:
This message conveys the cryptographic information which is sent by the server to the client and is used for generating the pre-master secret, which later will be useful for generating session keys for symmetric encryption.
5. Server Certificate Request:
Many times, in case of high securities, the server needs to authenticate the client certificate. Hence the server sends a server certificate request from the client mentioning the certificate type, certificate signature algorithms, and CA’s supported by the server (from the server trust store).
Lastly, the server sends the “Server Hello Done” message to the client and waits for the client’s retaliation.
6. Client Certificate:
When the server requests client authentication, the client acknowledges the same with a client certificate. Before sending the certificate, the client will verify the issuer DN with the server’s list of trusted CA’s. In case the issuer DN is missing, the client will refrain from sending the client certificate to the server.
This certificate should comprise the appropriate TLS version, confirmed cipher suite’s key exchange algorithm, and other confirmed extensions by both parties.
7. Client – Client Key Exchange:
This message is generated by the client and consists of the pre-master secret. The pre-master secret is an arbitrary random number generated by the client, and the same is encrypted with the server public key.
Since the client key exchange request is based on the cipher suite acknowledged by both the parties, it helps to generate a master secret, which is created by using the client-server random number, and the same is used to obtain the cryptographic keys for encryption.
Here the client encrypts the data with the server’s public key, and the same can only be decrypted using the server’s private key.
8. Client – Certificate Verify:
This message contains all hashed information exchanged during the handshake process and is digitally signed by the client. This message is proof to the server that the client possesses the private key related to the public key certificate.
9. Client – Change Cipher Spec:
This is a message sent by the client to notify the server that all the succeeding messages will now be encrypted using the acknowledged security variables.
Both the client and the server confirm that the handshake process is rolling in action as desired, identical keys have been generated, and the final encrypted finished message is sent to each other. This also indicates that the cipher suite is activated.
10. Finished:
An encrypted (cryptographic hash) finished message, along with the session key is sent to the server, by the client.
The server responds with a ChangeCipherSpec message to the client and informs about the future encryption messages.
Finally, the server sends an encrypted (cryptographic hashes) finished message to the client.
Wrapping Up:
Both the parties decrypt the finished message, verify the contents, and match the values by inputting the hash of handshakes.
The handshake process will be a success if the values match, and a secure communication channel is established between both parties. They can start transferring data on this secured channel.
But if there is some error in the verification process, then a “HandshakeFailure” message will be sent, and the session will be terminated.
Related Post:
