Thursday, April 11, 2024

SSL/TLS communication between Browser and Server

SSL/TLS Communication Between Browser and Server Demystified

Have you ever wondered how a browser communicates securely with a server, safeguarding sensitive data from prying eyes? In this post let's demystify the process of establishing a secure communication channel using SSL certificates, now being called TLS. Let's keep things simple, avoiding overly technical jargon for easy understanding

SSL Certificate - for Server: An SSL certificate for a server comprises crucial elements: a private key, a public key, and identity information like the server's domain. During the establishment of a secure connection, the server presents its public key in the form of a certificate to the browser. However, for browsers to trust this certificate, the public key must be certified by an authorized Certificate Authority (CA)

Certificate Authority (CA): A Certificate Authority (CA) is a trusted entity responsible for signing public keys and issuing them in the form of digital certificates. The CA maintains a pair of private and public keys, with the private key kept securely confidential. When an entity requests certification, the CA uses its private key to sign the entity's public key. This process ensures that the digital certificate certifies the ownership of the public key by the named subject of the certificate. Before signing the public key, the CA conducts necessary verification to confirm the identity of the requesting subject

Process of obtaining a Server certificate and getting it certified by CA:

  1. Create a Key Pair: Generate a pair of cryptographic keys consisting of a private key and a corresponding public key. The private key remains confidential and is used for encryption and decryption, while the public key is shared openly for encryption
  2. Create a Certificate Signing Request (CSR): Generate a CSR file that includes the public key along with essential information about the entity, such as its domain name and organizational details
  3. Submit the CSR to a Trusted CA: Send the CSR to a trusted Certificate Authority for verification and certification. The CA will validate the information provided in the CSR and authenticate the entity's ownership of the domain
  4. CA Verification and Certificate Issuance: Upon receiving the CSR, the CA performs necessary verification procedures to ensure the authenticity of the entity. If the verification is successful, the CA signs (certifies) the public key and issues a digital certificate to the entity. This certificate contains the entity's identifying information, along with the CA's digital signature, confirming the certification of the public key
  5. Use of Certified Public Key: With the issued certificate, the entity now possesses a CA-certified public key, which can be used to establish secure communication with clients. The certificate provides assurance to clients that they are connecting to a legitimate and verified server

 



Once the CA signs the server's public key, both the private key and the CA-certified public key are installed in the server's keystore. The keystore is a repository that securely stores cryptographic keys and certificates for use in SSL/TLS communication.

Additionally, the CA issues its own certificate, which serves as identification for the CA. For a Browser to trust the Server, the CAs own certificate needs to be present in the Browser's truststore as well. The truststore is a repository of trusted certificates, including those of CAs, used by the browser to verify the authenticity of certificates presented by servers during SSL/TLS communication.

By installing the CA certificate in both the server's keystore and the browser's truststore, a secure chain of trust is established. This ensures that when the browser receives a certificate (Server's public key) from the server during SSL/TLS communication, it can verify the certificate's authenticity by checking if it is issued by one of the CAs whose CA certificate is present in its truststore

 How Browser establishes a secure connection with Server

  • Browser initiates a secure connection with the server
  • The server returns its certificate that contains the public key
  • The browser verifies whether the server's public key is signed by one of the CAs whose CA certificate is installed in its truststore
  • The browser also verifies that the server's domain matches the domain name in the certificate
  • If the verification is not successful, like the Server's public key was not signed by a CA whose Certificate is present in the Browser's Truststore or the Client's Certificate is expired then Browser throws a warning
  • If the verification is successful, the browser generates a pre-master secret, a random value
  • The browser sends the pre-master secret, cryptographic algorithms to be used, protocol version, etc., to the server. This information sent by browser is encrypted with the server's public key
  • Server decrypts the information sent by Browser using its private key
  • From the pre-master secret and additional information, both the server and the browser derives a session key
  • The session key is used to exchange data between the client and the server
  • The session key is a Symmetric key, ensuring secure communication