Author Avatar

Anuj Verma


Share post:

Everyone of us have heard that data transferred over HTTPS is secured. As a result we provide our highly confidential information like bank details, credit card details to a website which runs overHTTPS .

Have you ever thought what makes your data secure when transferred over HTTPS ? How HTTPS makes sure that the data cannot be read by any intruder ?

In this article I am going to explain what goes behind the scenes when you submit your confidential information on a browser.

First let’s understand what is SSL, TLS, HTTPS ?

SSL (Secure socket layer ) — is a technology used for keeping an internet connection secure for transmission of any sensitive information between two systems. The two systems can be a client(like a browser) and server (like a bank application).

TLS (Transport layer security) — is just an updated, more secure version of SSL. The algorithms used in TLS are more secure.

HTTPS (Hyper text transfer Protocol SECURE) — is a protocol used to transfer data which is secured by SSL/TLS. So simply HTTPS is HTTP + SSL/TLS .

Now let’s take an example to understand how SSL/TLS works ? Suppose you are ordering food on website . In order to pay, you enter confidential information like card details on payment page presented to you in browser. Once you click on submit, this information is sent to the bank server which verifies the card details and responds with some message like transaction success or failure .

In the above scenario our client is Browser and the server is Bank server . Let’s go through the steps involved in the complete scenario after you clicked on Submit button on browser.


Before any actual data exchange client sends a “client hello” message to the server indicating that I want to establish a secure connection. This message includes client information like SSL/TLS version, supported cipher-suites and supported data compression methods.

Client browsers may be old and not supporting latest version of SSL/TLS, modern cipher suites etc. So they send this information to server in “client hello” message.

A cipher-suite is a set of cryptographic algorithms which can be used to encrypt/decrypt data like DES, AES, 3DES etc.


In response to “client hello” server responds with a “server hello” message which contains server information like the chosen cipher-suite from the list provided by client and itsdigital certificate.

After the above two steps, both client and server agreed on a SSL/TLS version and a cryptographic algorithm from the cipher suite which will be used for encryption/decryption.

STEP3: Server authentication

The client verifies server’s digital certificate sent in STEP2 by checking if the provided certificate is expired or not, is it issued by a trusted certificate authority or not, does the domain name in certificate matches server’s domain name or not. If the answer to all these questions is YES server authentication is successful.

Each SSL enabled client maintains a list of trusted Certificate authorities(CAs). The list determines which server certificate the client accepts. If the issuing CA is not in the list of the pre-determined CA list, server is not authenticated unless the client can verify a certificate chain ending in a CA that is on the list.

STEP4: Secret key exchange

The client generates one random string and encrypts it with server’s public key. After that it sends the encrypted string to server. Since the string is encrypted by server’s public key, no one can decrypt it without server’s private key. This encrypted string is used by both server/client to compute a secret key which will be used to encrypt/decrypt data exchange between them.

Note here that after this step both client and server have a common secret key which can be used to encrypt/decrypt data. It is known as a Symmetric key .

STEP5: Client HELLO finished

The client sends server a finished message, which is encrypted with the secret key, indicating that the client part of handshake is complete.

STEP6: Server HELLO finished

The server sends client a finished message, which is again encrypted with the secret key, indicating that the server part of handshake is also complete.

STEP7: Data exchange

For the duration of session, client and server can now exchange data that is encrypted with shared secret key. Since only client and server have the secret key, no one can read the messages in between.

So after STEP6 is completed, the actual data exchange between server and client can take place.

As you may have observed that in STEP3 client verifies the server’s digital certificate to make sure the client is talking to a genuine server. SSL/TLS has one more very interesting thing in which a server can also ask a client to prove its identity. It is known as Mutual TLS.

For example, when you access your browser verifies google’s digital certificate. Google never asks you to prove your identity by presenting a certificate. Mutual TLS can prove to be a very secure way for authenticating clients. In my next post, I will write about how mutual TLS works.

Thanks for reading and hope you learned something new. Feel free to comment if you have any suggestions or corrections.

Secure way of doing OAuth for SPA & Native Apps
7 amazing tips for Go developer

Leave a Reply