HTTPS made Easy

How HTTPS works under the hood

HTTPS works on basis of HTTP (Hypertext transfer protocol) which forms the basis of numerous applications that are hosted on the internet. In simple terms, HTTP is a request-response mechanism to exchange data over the internet. For example, if we want to go to Github’s website we enter www.github.com in the browser, and that’s a basic HTTP request which is taking place in the background. Most sites that we browse these days have a green padlock in the URL bar which when clicked show that the Connection is Secure which means we are using HTTPS. When compared to HTTP, HTTPS is deemed to be secure because it uses SSL/TLS under the hood to encrypt the communication between the sender and the receiver.

What is SSL/TLS?

SSL stands for Secure Sockets Layer and TLS stands for Transport Layer Security. You might hear people referring to both of them and use them interchangeably. That’s because, during the initial years of security when SSL was created by Netscape, it had a lot of vulnerabilities and problems. A lot of versions of SSL were released but none of them become the standard for web data exchange. Later down the line as SSL wasn’t gaining traction due to its bad history of bugs and issues, it was renamed to TLS.

Why is SSL/TLS secure?

The aspect that makes SSL/TLS secure is the handshake process. The way the handshake works is as follows,

Image Credits: https://code-maze.com/wp-content/uploads/2017/07/TLS-handshake.png

1. The client sends a ClientHello which just contains the information of the client’s supported SSL/TLS versions, cryptographic algorithms, etc.
2. The server responds with ServerHello which contains the information about what algorithm it choose from the list of algorithms that it received from ClientHello, the Server’s digital certificate along with the server’s public key, etc.
3. The client verifies if the received digital certificate is valid by contacting the Certificate Authority that issued the digital certificate.
4. Once the authenticity of the webserver is verified from the previous step, ClientKeyExchange takes place. In which a shared secret key for the purposes of Symmetric key encryption is encrypted with the Server’s public key received in Step-2.
5. The client sends a Finished message
6. The server now sends a Finished message encrypted with the key sent by the Client in Step-4, implying that the communication is encrypted.

Note: Digital certificate in simple terms is a certificate issued by some Certificate Authority (CA) which contains 2 things primarily. One thing is the public key of the Server, and the other is Digital Signature that’s been encrypted using private key of the CA who issued that certificate.

Certificate Authority in simple terms, is an entity that does due diligence of the company before issuing them a signed certificate which helps to prove the Authenticity of the company that uses the certificate. The way it works is all major web browsers come with public key’s of major Certificate Authorities throughout the globe. Browser can verify the Authenticity of the certificate by decrypting it using the corresponding public key it has. It’s works as follows, lets say I have my own company ABC with domain abc.com and I want to get a Certificate for encrypting communication between my server and the clients, using https. I go to a popular CA like Google, VeriSign etc and ask them to provide me a Digital Certificate(by creating a Certificate Signing Request(CSR), which we dont need to know about for now). The CA does their own checks and finally issue me a digital certificate which contains ABC’s public key and a digital signature signed using CA’s private key. So anyone who trusts that CA can trust the company ABC.

If some of the terms like public keys, private keys, digital signatures, authenticity sound alien to you, I highly recommend going through my articles that talk about Types of Keys, Authentication and re-read this article :)

After these steps are completed, communication between the Client and Server happens in an encrypted fashion.

How it adds up to HTTPS?

Let's see this with an example. Consider a client and a server(say abcde.com). The client makes a request to abcde.com and the server responds with a digital certificate that contains the public key of abcde.com and the Certificate Authority’s signature. Client’s browser checks its list of available public keys, for the CA who issued the digital certificate to abcde.com. Using that public key it tries to form trust by verifying the Authenticity of the CA. Once that’s done the Client creates a secret key (a.k.a Session Key) which it encrypts using abcde.com’s public key so that no one except abcde.com can view the contents of the message i.e., the Session key. Once the key is received by the Server (abcde.com) all the communication between the client and server is encrypted using that Session key.

Note: The reason communication happens using Symmetric Key Encryption rather than Asymmetric key encryption is that its less resource intensive and can be run on almost all devices.