Skip to main content

SSL Certificate and Handshake Process

A protocol is a set of rules which defines, how a particular thing will happen. HTTP is a network protocol which allows the fetching of resources, such as HTML documents. It is the foundation of any data exchange on the Web.

We usually see a lock symbol in websites which has https. Here, "s" stands for security. To achieve this security, another protocol "SSL/TLS" is used. SSL is an encryption protocol which ensures the encrypted communication between two parties (i.e. client and a server). SSL (Secure Socket Layer) is now known as TLS (Transport Layer Security). 

To achieve a secure communication between client and server using SSL/TLS, a series of steps happens which are known as SSL/TLS Handshake.

Note

  • SSL Certificate works on a TCP (Transmission Control Protocol) protocol to send data over the internet.
  • All TLS handshake works on Public Key Cryptography. Public-key cryptography or asymmetric cryptography uses a pair of keys to encrypt and decrypt the data. The public key is used for encryption purposes and the private key is for decryption. Public Key is shared with everyone who receives the certificate upon visiting a website on internet which is secured with SSL.
  • SSL can be implemented either one-way or two-way. In one -way SSL, only the client validates the identity of the server whereas in two-way (mutual) SSL, both server and client validate the identity of each other through the digital certificate so that both parties are assured of the others' identity. Usually, 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 is mostly used in server to server communication where both parties need to validate the identity of each other.

SSL/TLS Handshake

1. Handshake initiates when client (usually a web browser) sends a "hello" message to the server. The message includes the information like which TLS version the client supports, the cipher suites supported and a client random etc.

2. In reply to the client's hello message, the server sends a message containing the information like server's SSL certificate, the server's chosen cipher suite and a server random.

Note: 
When we request Certification Authorities (CAs) to issue a SSL certificate (for this, we basically generate the private-public key pair and then use the public key to create the CSR, along with the domain and other details about your organization. The CSR is sent to the CA. CAs then verify the information in the CSR and issue the certificate. Here to note is that, when we select the self managed certificate in GCP ALB/Azure App Gateway, we have to upload the certificate along with private key (of the private-public key pair used to create CSR) in .pem/.pfx format).
CAs issue a certificate by encrypting the data like (the CA's issuer name, your server's public key, company name, domain, certificate validity, SSL/TLS Version etc.) using their private key. along with CAs digital signature.

Almost most of the web browser comes with the public keys of all of the major certification authorities. Web browser uses this public key (CA's Public key) to verify that the a website's certificate was indeed signed by the trusted certificate authority or not.

3. The client verifies the server's SSL certificate with the certificate authority that issued it. This confirms that the client is interacting with the actual owner of the domain.

4. Client creates a pre-master secret for the session and encrypts it with the server’s public key. which can only be decrypted with the private key by the server, since only the web server has its private key. Remember, The client gets the public key from the server's SSL certificate.

5. The server receives pre-master secret and decrypt it with the private key.

6. Both client and server generate session keys from the client random, the server random, and the premaster secret. They both arrive at the same results. 
Now this key will be used by both the client and server for encryption and decryption of the data transferred between them for that session only. This is something known as symmetric key cryptography.

7. The client sends a "finished" message to server which is encrypted with the session key.

8. The server sends a "finished" message to the client which is encrypted with the session key.

Notes

  • The above explained way was an example of RSA Key exchange algorithm during TLS Handshake. Other could be Diffie-Hellman.
  • As we have seen, after mutual agreement upon session key, encryption and decryption both will happen using the same key. Hence Handshake process is a combination of Asymmetric and Symmetric encryption. 
  • The certificate authority (CA) is essential to preventing man-in-the-middle attacks.


Source: Internet

Labels: