Why https:// required theses days why it required? Well you will get the answer of it and you will know better what https:// and how does it work in this blogpost.
Let’s dive right in without https:// the communication between the browser and the server is in plain text.This mean that the password you enter or credit card number you send over the internet can be read by anyone who has the ability to intercept it.
Https is designed to solve this problem. To make the data sent over the internet, unreadable by anyone other then the sender and the receiver.Note: Https is an extension of the http protocol.
With https data is sending an encrypted from using something called TLS. TLS stands for Transport Layer Security. If the encrypted data gets intercepted by a hacker all they could see is jumbo data.
Let’s take a look at how the TLS handshake works there are several steps.
Step 1 : Just like in the care for http the browser establishes a TCP connection with the server.
Step 2 : This is where the TLS handshake ???? begins. The process sends a client hello to the server in this hello message the browser tells the server the following things.
One: What TLS version it , it can support it could be TLS 1.2 TLS 1.3 etc.
Two: What cyber suit that that supports a cyber suit is a set of encryption algorithms to use to encrypt data. They are receiving the client hello the server gets to choose the cyber and the TLs version to use based on the options. It got from the client it sends those in the server hello message back to the client.
The server then sends the certificate to the client the certificate includes a lot of different things one of the key ????? things is the public key for the server. The client uses the public key in something called asymmetric encryption. In a symmetric encryption a piece of data is encrypted by a public key can only be decrypted by the private key.
We’ll discuss how this is used in a bit. This concludes step two . The hello phase of the TLs handshake at this point the client has a service certificate and the client and server have agreed on the TLs version and the cyber suit to use.
Step 3 : Now step 3 this is the step where the client and the server comes up with a share encryption key to use to encrypt data and this is where the asymmetric encryption come into the picture again with asymmetric encryption the data encrypted on the client side using the public key from the server can only be decrypted by the server. This is how the client send an encryption key safely to the server over the wide open internet. All this is done in the client key exchange message the exact details varies depending on the cyber suit used here.
We use TLs as an example since it is the easiest to understand with TLs the client generates an encryption key also called a session key. Encrypt it with the server public key ????? and server encrypted session key to the server over the internet the server recives the encrypted session key and decrypts it with its private key now both sides hold the session key and this is whose they enter step 4 of the TLs handshake where they use the session key agree upon cyber suit to send encrypted data back and forth in a secure bi-directional channel.
Now youay ask why don’t we just use a symmetric encryption for everything. Why switch to symmetric encryption at all the main reason is that asymmetric encryption is computationally expensive.
It is not really suitable for bulk data transmission before we close there are two final points. I would like to discuss first the handshake we talked about applied to TLs 1.2 while the latest version is TLs 1.3 and TLs 1.3 supported on all major browsers as we can see in our illustration. TLs 1.2 take two networks round trips to complete this is one of the major improvement of TLs 1.3. It optimize the handshake to reduce th number of networks round trips to one. We decided to talk about TLs 1.3 because we reviewed TLs 1.3 as in optimization as with most optimization. It is a bit harder to explain that’s vwhy we choose TLs 1.2 instead the core concepts in TLs 1.2 still applies to TLs 1.3.
The second final points ibwould like to discuss is that in the explanation above we use TLs for asymmetric encryption bto securely exchange the symmetric session key again we choose to TLs because it is easy to understand. However asymmetric encryption is not only way to share the session key between the client and server in fact in TLs 1.3 TLS no longer supported as the method for key exchange diffie-hellman is a more common way nowdays for exchanging session keys. Tiffy helmet is complicated but in a nutshell it is used some advanced match involving large prime numbers to derive a share session key without ever transmitting a public over the network.
This is it for https you like to learn more and amazing. Please follow us and stay tuned to our official facebook pages for the new comming blogpost.
Thank you so much I will see you on next time.
Thank you!!!
