This article is going to reveal the dust from the HTTPS detailing panel. we will learn how does HTTPS work?

Introduction to HTTPS

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP)

What is so important about https that these days, most websites require it?

How does https work?

we’ll answer this question in this post. Let’s dive in.

How does HTTPS Work?

Without https, the communication between the and the server is in plain text. this that the password you enter, or the credit card card number you send over 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 than the sender and the receiver. https is an extension of the HTTP protocol.

TLS

with https, data is sent in an encrypted form using something called TLS.

TLS stands for Transfer Layer Security.

If the encrypted data gets intercepted by a hacker, all they could see is jumbled data. this is where TLS handshake comes in.

If You are willing to do Masters in computer science in INDIA must read this

TLS handshake

Let’s take a look at how this handshake works. there are several steps.

• Just like the case for HTTP, the browser establishes a TCP connection with the server.
• This is where the TLS handshake begins. the browser sends a “client hello” to the server.

in this hello message,
the browser tells the server the following things:

• What TLS versions it can support. it could be TLS 1.2, TLS 1.3, so on forth.
• What cipher suites it supports. A cipher suite is a set of encryption algorithms to use to encrypt data.

After receiving the “client hello” the server gets to choose the cipher suite and the TLS version to use based on the options it got from the client.

It send those in a “server hello” message back to the client. The server sends a certificate to the client. The certificate includes a lot of different things.

Client key exchange message

One of the key things is the public key for the server. The client use the public key in something called asymmetric encryption. In asymmetric encryption, a piece of data that 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 server certificate, and the client and the server have agreed on the TLS version and the cipher suite to use.

Now onto step 3 this is the step where the and the server come up with a shared encryption key to use to encrypt data. this is the puzzle we talked about earlier. And, this is where asymmetric encryption, the data encrypted on the client side using the public key form the server can only be decrypted by the server.

this is how the client sends an encryption key safely to the server over the wide open internet.

All this is done in the “client key exchange” message. the exact detail varies depending don’t he cipher suite used. here we use RSA as an example since it is the easiest to understand.

with RSA, the client generates an encryption key (also called a session key), encrypts it with me server’s public key, and sends the encrypted session key to the server over the internet.

the server receives the encrypted session key and decrypts it with this private key.

So, now the server has the session key, too.

Now, both sides hold the session key. and this is where they enter step 4 of the TLS handshake.

Session key in TLS Handshake

In this step they use the session key and agreed upon cipher suite to send encrypted data back and forth in a secure bi-directional channel. Now you might ask:

Why don’t we just use asymmetric encryption for everything?

Why switch to asymmetric encryption at all?

the main reason is that asymmetric encryption is computationally expensive. this is not something suitable for bulk data transmission.

Now, before we close, there are two finer points I would like to discuss.

Version TLS 1.2 vs TLS 1.3

First, the handshake we talked about applied to TLS 1.2, while the latest version of TLS is 1.3.

And, 1.3 is supported on all major browsers. as we can in our illustration, TLS 1.2 takes two network round trips to complete.

this is one of the major improvements of TLS 1.3. IT optimizes the handshake to reduce the number of network round trip to 1.

we decided to talk about TLS 1.2 because we view TlS 1.3 as an optimization.

as with most optimizations, it is a bit harder to explain.

that’s why we chose TLS 1.2 instead.

The core concepts in TLS 1.2 still apply to 1.3. the finer point we would like to discuss is that, in the explanation above, we used RSA for asymmetric encryption to securely exchange the symmetric session key. Againwe chose RSA because it is easy to understand . however, asymmetric encryption is not the only way to share the session key between the client and the server.

In fact, in TLS 1.3, RSA is no longer supported as a method for key exchange.

Differ-Hellman for key exchange

Differ-Hellman is a more common way nowadays for exchanging session keys.

Diffie-Hallman is complicated, but in a nutshell, it uses some advanced math involving large prime numbers to derive a shared session key, without ever transmitting a public key over the network.

Well, that’s it for https.

If You are willing to do Masters in computer science in INDIA must read this

How does https work?

In brief, HTTPS arises based upon the communication of TLS/SSL certificates, which verify that a particular provider is who they say they are. When a user joins to a webpage, the webpage will send over its SSL certificate which retains the public key required to start the secure session.

Some Questions often asked about HTTPS