How HTTPS or SSL/TLS works
Have you ever wondered how HTTPS actually works. In this blog, I would try to explain this. But at first, look what we have before HTTPS, Yeah you are right, we have HTTP and working of HTTP is so simple. In HTTP data is transmitted between clients (eg: web browsers such as chrome, firefox) and server as plain text. So that any attacker, intruder can easily intercept your request, response data payload, and can hack you. That’s why we create a secure channel i.e. HTTPS over HTTP.
In HTTPS there is use of both asymmetric (public key cryptography) and symmetric cryptography. If you are even beginner, don’t get confused on this term, let’s keep in mind, in public key/asymmetric cryptography there is use of separate key ie public key and private key for encryption and decryption whereas in symmetric cryptography there is use of same single key for both encryption and decryption.
At the end of the day, the basic idea behind HTTPS is to send data between Client and Server in encrypted format using Symmetric key cryptography. In symmetric-key cryptography, as I already said, server and client should have the same key to encrypt and decrypt messages. So to share this key securely between server and client, again there is the use of Asymmetric key cryptography. Get confused right? Let’s understand this process in steps
- After browser send a request, at first Server sends its public key to the browser .
- Browser generate Random Session key and encrypt this key using received public key of server.
- Browser sends this encrypted session key to server and server decrypt that received key using his ownprivate key.
- Now both have session keys which can be used to encrypt and decrypt messages.
Quite Simple right, But in reality, there is one more problem,i.e in the above approach, attacker can stand in the middle, intercept the server response, and instead of sending server/website real public key, he can send his own public key to browser/client, so that he can intercept all message, data payload and can hack. To solve this problem we need to make sure that the public key is exactly from the actual server, not from an attacker, intruder proxy. To make these things sure, researchers back in the time, agreed to use digital certificates which verify that the public key is from a genuine site that we want to surf
So now let's combine all this actual SSL process like where when what is happened by how in the following steps,, Sound goods? okay cool let’s dive
- First of all, the user creates a public key and private key for his website (suppose a website ‘www.abc.com’). Then he sends his public key along with other personal information such as his driving license to a Certificate authority (CA). CA first verifies whether this site belongs to him or not, if verified then CA signs these details using his own private key( i.e CA private key) and sends this back to the user. In the webserver user store that certificate. [Note there are several CA such as lets encrypt, open ssl, godaddy. Infact this CA again trusted another CA. So overall there is a chain of CA and at the end there is Root CA. Also instead of using this CA, you can create own CA and generate certificate know as self signed certificate, but by default browser does not trust your CA, so you have to manually install your CA cert in browser locally.]
- Now at the time of communication, web surfing following steps occurs
- First user click website eg: ‘www.abc.com’ in the web browser which will initially send a hello request to the server
- Server get this request and before sending any data to client,he sends his certificate to the browser
- Browser receives a certificate and at first, it checks whether the issuer of this certificate which is CA is trusted or not. This is done by, browser already have a list of trusted CA in his setting, if it does not found, its mean browser doesn’t trust that CA and show error
- Now if the browser trusts that CA, it checks the validity of that certificate to check whether the certificate is tempered or not by a hacker. This is done by, browser already has the public key of that CA, and it uses that key to verify the validity of the certificate. Also, other info such as expiry date of the certificate is verified.
- If it is valid, it is sure that the public key is valid and sends from genuine website ie ‘www.abc.com’, and upcoming steps after this steps, we already described above, ie browser generate a session key, encrypt that session key using the public key of server which is received in the certificate, then send this encrypted that key to the server, server decrypt that using his private key, now both have sam session key, ie now communication established, first send a response of ‘www.abc.com’ to the browser in encrypted form and proceed other communication. This session key is valid for a session such as until the browser close, or up to a certain time. Till this session, same key is used for encryption, decryption, but after the ending of the session, if the user again requests site then this process of sending certificate by the server, validation in the browser, encryption is repeated again.