SSL handshake

How does a TLS handshake work? | CyberNcrypt

ByCyberNcrypt

TLS is a protocol for encryption that is used to protect Internet communications. The procedure that begins a communication session using TLS encryption is known as a TLS handshake. The two communicating sides exchange messages during a TLS handshake to recognize one another, confirm one another, decide on session keys, and specify the encryption techniques they will use. TLS handshakes are a crucial component of how HTTPS functions.

TLS vs SSL handshakes

Secure Sockets Layer, or SSL, was the first encryption standard created for HTTP. TLS, or Transport Layer Security, has long since supplanted SSL. TLS handshakes have replaced SSL handshakes, however, the term “SSL” is still often used.

What happens during a TLS handshake?

A client and a server exchange a number of datagrams, or messages, during a TLS handshake.  In order to complete the handshake and enable future communication, the client and server must exchange information in numerous steps during a TLS handshake. Depending on the type of key exchange mechanism employed and the cipher suites supported by both parties, the precise steps inside a TLS handshake may change. 

The most popular key exchange algorithm is RSA. 

It goes like this:

  • The “client hello” message is sent by the client to the server to start the handshake. The message will comprise the cipher suites supported, the TLS version the client supports, and a group of randomly generated bytes known as the “client random.”
  • The “server hello” message is sent by the server in response to the “hello” message from the client. It contains the server’s SSL certificate, the cipher suite it has chosen, and another random string of bytes it has generated called “server random.”
  • Authentication: The client checks the SSL certificate of the server with the organization that issued it. This demonstrates that the server is who it claims to be and that the client is communicating with the legitimate domain owner.
  • The client delivers a last random string of bytes, known as the “premaster secret.”  Only the server has the private key needed to decrypt the premaster secret, which is encrypted with the public key. (The client obtains the public key from the SSL certificate of the server.)
  • The server uses a private key to decrypt the premaster secret.
  • Both the client and the server build session keys using the premaster secret, the client random, and the server random. They ought to reach the same conclusions.
  • The client is ready: The client sends a “finished” message that is encrypted with a session key.
  • The server is ready: The server transmits a “done” message that has been encrypted with the session key.
  • Once the handshake has been performed and the session keys are being used for communication, secure symmetric encryption has been established.