One of the most basic knowledge required for web developers is to know how https protocol works (also called SSL/TLS).
How does it secure your websites compared to http?
Let’s first see why http is not secure.
Assume you are in a public wifi network.
You are using the wifi to connect to the internet.
A hacker is hacking all the web traffic over that wifi.
And you are hitting a website , say http://somewebsite.com
Let’s say you are sending some data to that website.
This is in plain English.
The hacker will be able to read that.
Your IP address will be available in the HTTP header and the hacker can know your laptop as well.
Once the server gets the request , it responds again in plain English.
The hacker will be able to read that data as well.
Now let’s see how this is different in HTTPS.
In HTTPS , this data will be encrypted, so the hacker won’t understand .
Encryption is done using some key right?
So if the hacker knows what the key is , he can decrypt the data using the same key , isn’t it?
But the problem is , he will never know the key to decrypt data.
How is this possible?
How does the browser know the key so that it can encrypt the data and send it to the server?
How does the server know the same key so that it can encrypt the response and send it to browser?
This is made possible through the use of three keys:
- public key
- private key
- session key
and the concept of public key cryptography.
In this type of cryptography data is encrypted using a public key.
Anyone has access to this public key.
But the encrypted data can only be decrypted using a private key.
This private key is not available to the public and so only those know the private key can decrypt the data.
How does the browser get this public key?
The server sends it in a digital certificate the first time the browser and the server establish a connection.
The digital certificate has the public key and the signature of a certification authority.
The browser then verifies if the website is valid by checking the digital certificate. These certificates are issued by Certification Authorities(CA) and the major CA details are already available with the browsers so that they know if the signature of the CA is valid or not.
Once the browser verifies the website , it extracts the public key from the digital certificate.
It then creates a session key and encrypts that session key using the public key .
A key used to encrypt another key!
This data is sent to the server.
The server then decrypts this key using its private key. This private key is available only with the server. The browser will never know it. After decrypting it gets the session key.
All further data exchanged between browser and server is encrypted using this session key.
The browser doesn’t even have to know the private key maintained by the server!
The hacker can never know the session key because he does not have the private key to decrypt the encrypted session key which the browser sends to the server.
Here is the algorithm to summarize:
- Browser hits website protected by HTTPS
- Server sends digital certificate
- Browser extracts public key from certificate
- Browser creates a session key
- Browser encrypts the session key using the public key and sends it to server
- Server decrypts session key using its private key
- Browser sends requests encrypted with the session key
- Server sends responses encrypted with the same session key
The browser knows the public key and session key.
The server knows the public key, private key and session key.
The hacker can only know the public key!