How does TLSV1.2 works
Question:- Explain what is HTTPS and why do we need it ?
Answer → This is required, in order to make sure that, data in transit can be made secure.
Question:- In case of https, what would happen, if someone tries to read the information ?
Answer → The hacker would only be able to see the encrypted information.
Question:- Explain the process of SSL-TLS-Handshake ?
Answer → First & foremost, Browser establishes the TCP Connection with the Server.
Now, the TLS-Handshake begins :-
Step 1.) Browser sends the Client-Hello to the Server. Through this message, browser tells to the Server following things :-
- The TLS-version it can support. For example, it can be either TLS-1.2 OR TLS-1.3 etc.
- The Cipher-Suite it supports. Cipher-Suite is a collection of algorithms, used to encrypt the data.
Step 2.) Now, after Server receives the ClientHello message, it now chooses the TLS-version and Cipher-Suite, from the options that Browser sent to the Server. Server confirms back this information in Server-Hello message.
Step 3.) Server now sends a Certificate to the Client. This Certificate includes a lot of different things. One of the crucial part of this message is : Public-Key for the client.
- This Public-Key is part of the Asymmetric Encryption Approach, where public-key is being used by the Client to encrypt the data.
- This data can only be decrypted by the Private-Key only.
Step 4.) At this step, Symmetric-Encryption comes into the picture. Now, Client (Browser) & Server comes up with a shared-encryption-key, in order to encrypt the data. This shared-encryption-key is itself encrypted with the public-key that browser received in aforementioned steps. This is how, the Browser safely sends the shared-encryption-key to the Server via the open-internet on the wire. This shared-encryption-key is also known as encrypted-session-key.
Note the following aspects :-
- The Blue-colored key (as shown in the left part) is Public-Key, through the help of which Client first encrypts the session-key.
- The Red-colored key (as shown in the right part) is Private-Key, through the help of which Server decrypts the session-key.
- This step is usually achieved via the RSA-Algorithm.
Step 5.) At this step, Client (Browser) & Server communicates happily using this encrypted-session-key.
Question:- Why not to use the ASymmetric-Encryption throughout ?
Answer → Because the Asymmetric-Encryption is quite computationally expensive. Therefore, we have to look for an alternative solution somehow. Overall TLS-handshake process now looks something like this :-
Question:- What are the disadvantages of TLS V1.2 Handshake process, as shown above ?
Answer → This includes the TWO mandatory Network Round Trips. Therefore, a more optimised version also exists i.e. TLS V1.3.
Question:- Why we choose the RSA-Algo in order to safely exchange the Symmetric-Encryption-Key (aka Session-Key) ?
Answer → Because, RSA is easy to understand.
Question:- Whether TLS V1.3 is being supported by all major browsers
Answer → Yes, TLS V1.3 is being supported by most of the modern browsers.
Question:- What are optimisations done into TLS V1.3 ?
Answer → Following are the optimisations done with TLS V1.3 :-
- It optimises the TLS-handshake process and completes the same with only ONE Network Round Trip.
- In order to safely exchange the Session-key (aka Symmetric-Encryption-Key), the RSA algorithm is no-longer supported at all, rather we now use Diffie-Helman algorithm. This Algo involves complex maths and makes use of large prime numbers, to derive a session-key, without ever exchanging the public-key over the Internet.
That’s all in this blog. If you liked reading it, do clap on it. We shall see you in next document..