Analyzing SSL Handshake Logs
SSL 101
We are in an era of online businesses and for good or bad, we are in a path of becoming an online life form. Meanwhile, cybercrimes and attacks are becoming more of a threat to businesses at each passing day.
If you are an online business owner or stakeholder, one of your main goals is to create a trusted environment for your consumers. You have to win the faith of customers that their money and sensitive details are secured with you. Consumers won’t purchase unless they feel safe with their money and have the trust of receiving the purchased product or service.
In the modern era, the SSL is one of the key elements that create the foundations of trust by establishing a secure connection.
The SSL ensures that the internet connection between two systems and the sensitive data transferring between those two systems is secure which prevents cybercriminals from compromising any information transferred. If you visit an SSL secured website, you will receive a visual indication as below.
So what is this SSL?
The SSL stands for Secure Socket Layer.
Let me give you some insight into where this SSL protocol runs.
You might have heard that TCP/IP (Transmission Control Protocol/Internet Protocol) governs the transport and routing of data over the internet. The HTTP protocol runs on top of TCP/IP to support application tasks such as presenting web pages and running relevant functionalities.
The SSL protocol runs above the TCP/IP and below the HTTP. The SSL uses TCP/IP on behalf of HTTP and establishes an encrypted secure connection between two communicating parties (client and server). With the SSL protocol in place, an eavesdropper can only see the connection endpoints but cannot read or modify any of the actual data. Hence it protects users’ sensitive data.
Let’s see how the SSL does that?
That is where the SSL-Handshake comes into play.
Deep Dive into SSL Handshake
The SSL-Handshake allows an SSL-enabled server to authenticate itself to an SSL-enabled client and also allows the client to authenticate itself to the remote server. During the handshake, both parties exchange important and unique information that establishes the aforementioned secured connection.
There are two types of SSL-Handshakes:
- One-way SSL
- Two-way SSL (Mutual SSL)
There is a major difference between these two types of handshakes.
In a one-way SSL, the client validates the identity of the server whereas, in two-way SSL, both the server and the client validate the identity of each other.
Let’s discuss the steps of SSL-Handshake in more detail.
The SSL-Handshake mainly consists of the following steps.
- Client Hello
- Server Hello
- Certificate Chain
- Server Key Exchange
- Certificate Request (only in two-way SSL)
- Server Hello Done
- Client Key Exchange
- Client Change Cipher Spec
- Client Finished
- Server Change Cipher Spec
- Server Finished
The following diagram illustrates more on the flow.
Let me explain what each step means.
- Client Hello
The first message is called ‘ClientHello’ which is sent from the client to the server. ClientHello is responsible for sending the fundamental details required by the server to establish a secure connection.
The ClientHello message carries the details such as:
- SSL or TLS version
- Cryptographic algorithms
- Data compression methods supported by the client
- Client random
The given handshake logs show that the ClientHello has been sent with TLS v1.2 which tells the server of the supported and preferred TLS version. Also, it shows the list of ciphers that are supported by the client.
Forgot to mention.
The TLS stands for Transport Layer Security who is the successor of SSL. The later versions of SSL come under the TLS.
Once the server receives this message, it selects a suitable cipher suite that it supports from the given cipher suite list by the client. The server will ignore other ciphers that are not recognized or supported. The selection process that happens here leads to the second step, ServerHello.
2. Server Hello
As the name indicates, the ServerHello is sent by the server. The ServerHello message tells the client what are the connection parameters that have been selected by the server from the provided list.
The server considers the received TLS version with the ClientHello and selects the highest supported version which is equal or lower to the client’s suggestion. Also, it will select a cipher suite from the presented list of ciphers.
Generally, the ServerHello consists of:
- Agreed SSL/TLS version
- Session ID
- Agreed cipher suite and other relevant details
- Server random
If the client and server don’t have any common attributes the SSL handshake fails at this point.
3. Server Certificate Chain
The Certificate Chain message is sent by the server along with the ServerHello. This particular message consists of the server’s SSL certificate and it’s the intermediate certificate chain.
To establish trust between both parties, the server should have a valid SSL certificate signed by a Certificate Authority (CA).
Once the certificate is received, the client contacts the server’s CA and verifies the server’s digital certificate thus confirming the authenticity of the server. The verification process might consist of:
- Validating the certificate’s digital signature
- Verifying the certificate chain
- Checking for certificate details such as domain name, expiration date, etc.
If the client finds a valid certificate, you will receive a ‘Found trusted certificate’ message followed by the ‘Certificate chain’ at the client-side logs.
4. Server Key Exchange
The ‘ServerKeyExchange’ message is an optional message which is sent by the server to the client. The client uses the details received from the Server Key Exchange message to generate the pre-master secret.
This message is only required in the Elliptic Curve Diffie-Hellman (ECDH) key exchange algorithm and won’t be seen in other mechanisms such as RSA key exchange, which don’t require the information from the server to generate the pre-master secret. The ECDH key exchange algorithm sends the following public key details to the client.
Let’s discuss the differences between these algorithms and handshakes based on them later.
5. Certificate Request
The ‘CertificateRequest’ message is the first indication we get to differentiate the one-way SSL from the two-way SSL. During the one-way SSL, the client validates the authenticity of the server. The authenticity of the client is not checked. However, in two-way SSL, both parties validate the authenticity of each other.
So how does the server validate the client?
It’s kind of the same as how the client does it.
At this step, the server sends the CertificateRequest with the details of expected certificate type, certificate signature algorithms, and certificate authorities. It’s the client’s responsibility to send the certificate from its arsenal to the server matching the requirement. However, there is a wild card at this step. If the server sends an empty list of certificate authorities, depending on the client’s implementation, it can decide whether to send the certificate or not.
Here is what a Certificate Request looks like.
The client sends its certificate chain matching the requirements sent in the Certificate Request.
If the server finds a valid certificate, you will receive a ‘Found trusted certificate’ message followed by the ‘Certificate chain’ message at the server-side logs.
6. Server Hello Done
The ‘Server Hello Done’ message indicates the end of ‘Server Hello’. By this point, the server has sent over all the details required to the client and is waiting for the client’s response. You will see the after the Certificate Request message.
7. Client Key Exchange
At this point, the client generates a random string of bytes called ‘pre-master secret’ based on the selected key exchange method selected during the initial ‘Hello’ messages.
If RSA is used, the client generates the pre-master secret. Then the client encrypts the pre-master secret with the server’s public key and transmits it to the server. Only the server has the matching private key to decrypt the message and get the pre-master secret generated by the client.
If the Diffie-Hellman is used, the required Diffie-Hellman parameters are transmitted to allow both client and server to generate the same pre-master secret.
Please be noted that the public keys are stored on digital certificates for secure transport and sharing. Hence the client receives the server’s public certificate along with a Certificate Chain message.
After having the pre-master key, both sides generate the master key, or else we can say the symmetric session key, based on it.
8. Client Change Cipher Spec
Then the client generates a ‘Change Cipher Spec’ message letting the server know that it’s going to switch to an encrypted communication based on the session key.
9. Client Finished
The ‘Finished’ message is sent by the client to the server indicating that the client’s side of the handshake has been completed. The client’s ‘Finished’ message is encrypted by the shared session key and it’s the first message protected by it.
This message consists of required data that provide the guarantee for the server that the handshake hasn’t been compromised.
10. Server Change Cipher Spec
The server decrypts the received message and finds the pre-master secret sent by the client. Then it computes the session key based on the pre-master key, which will be used in the following communication.
At this point, the server generates its own ‘Change Cipher Spec’ message to indicate that it’s also switching to encrypted communication.
11. Server Finished
At last, the server also generates a ‘Finished’ message encrypted by the session key. This marks the end of the server part of the communication as well as a successful SSL handshake.
Once this handshake is done, the server and client now can exchange messages that are symmetrically encrypted with the shared session key.
Now you know about the general flow of SSL handshakes. But there can be some slight variations for it based on the used key exchange algorithm. There are mainly two key exchange algorithms used in TLS.
- RSA key exchange
- Diffie-Hellman key exchange
Let’s have a close look at both.
RSA vs Diffie-Hellman
There are some fundamental differences between Diffie-Hellman and RSA. If we put in simple words, RSA can handle both the authentication based on digital signature and the secure key exchange whereas Diffie-Hellman only handles the key exchange. Hence the RSA can be named as the more capable method of the two.
Often you will see that the Diffie-Hellman is often combined with Elliptic Curves making the Elliptic Curve Diffie-Hellman (ECDH). Including ECDH, there are four main branches of Diffie-Hellman.
- Diffie-Hellman (DH)
- Diffie-Hellman Ephemeral (DHE)
- Elliptic Curve Diffie-Hellman (ECDH)
- Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)
Since the Diffie-Hellman is lacking the authentication part, it needs to be paired with a digital signature algorithm. Nowadays you will often see few modern variants of Diffie-Hellman such as ECDH and ECDHE are paired with Elliptic Curve Digital Signature Algorithm (ECDSA) or RSA.
RSA based Authentication and Key Exchange
The authentication and key exchange processes of RSA have been entangled with each other. The key exchange is performed as a part of the RSA’s authentication process.
If the RSA is used and the client receives the server certificate, a set of actions are performed to verify the validity of it.
- Validates the digital signature using the public key
- Check the certificate chain and verify that the server certificate is available in the client trust store or it descends from a root certificate in the trust store.
- Check the validity period of the certificate. If the certificate has been expired the handshake fails.
If the certificate passes all the verifications, the client uses the public key received with the certificate to encrypt the pre-master key and send it over to the server.
What if the client receives a different certificate that is yet to be valid than the actual server certificate.
Since it’s a valid certificate, it passes the client’s verification of the certificate signature. But how does the client know that the server owns the private key that signed the certificate?
The client sends back the pre-master key encrypted with the server’s public key. Hence, it only can be decrypted using the server’s private key. If the server can decrypt and get the correct pre-master key, it validates that the server owns the private and public key pair used in the process.
That explains how the RSA-based authentication happens, which lets us move for the key exchange.
Here is how it happens,
- During the Client Hello and Server Hello, both parties exchange two prime numbers called ‘client random’ and ‘server random’ respectively.
- The client generates the pre-master key, encrypts it using the server’s public key, and sends it over to the server.
- The server decrypts the received pre-master key using the corresponding private key.
- At this point, both parties should have client random, server random, and pre-master key.
- Using the aforementioned parameters, both client and server generate matching session keys.
It seems to be a good time to know how DH acts to accomplish these tasks.
Diffie-Hellman based Authentication and Key Exchange
As we have mentioned earlier, the DH cannot perform the authentication process by itself. Hence it associates with digital signature algorithms such as ECDSA or RSA.
However, please be noted that, even though RSA uses the key pair for both authentication and key exchange, the DH uses the key pair only for the authentication.
If the DH is in use, similar actions are performed as in the RSA by the client upon receiving the server certificate.
- Validate the certificate signature
- Check the certificate chain
- Check the validity period and other relevant details
How does the client validate the key pair?
During the Client Hello and Server Hello, both parties exchange two prime numbers called ‘client random’ and ‘server random’ respectively. As we have mentioned earlier, the Server Key Exchange step is only specific to the DH handshake. Before the Server Key Exchange, the server takes the server randomly and the client random and the server’s DH specific parameters and then encrypts them using the server’s private key which will work as the digital signature. Then the client uses the corresponding public key to verify that the server owns the private and public key pair used in the process.
So how does the DH key exchange happen?
Not like in RSA, the required parameters are transmitted to both parties to generate the same pre-master secret.
Here is what happens,
- Both parties exchange two prime numbers called client random (x) and server random (y) respectively during the client and server ‘Hello’ messages.
- The client selects a secret number called pre-master secret (a) and applies a modulo function as xa mod y.
- Similarly, the server selects its pre-master secret (b) and applies a modulo function as xb mod y.
- Let’s name the client’s result as A and the server’s result as B.
- Both parties then exchange the value and apply another modular function. The client applies Ba mod y and the server applies Ab mod y.
If the functions and values are applied correctly, both parties should have the same value which we called the session key. As we already know, the later communication between these two parties will be encrypted using the retrieved session key.
That’s it then.
Now we know the end-to-end details of how communication happens between client and server. We have discussed how the one-way SSL differs from the two-way SSL and how to identify it from SSL logs. Also, we have covered how the handshake varies based on the used key exchange method.
The entire process is guaranteed to establish trust between both communicating parties. In the current era, SSL is considered to be an essential part of secure communication. It’s fascinating to see how users put their faith in this protocol about the safety of their sensitive details that are being transferred through the internet.
Stay safe! Be secure!
