From historical times, humans have been communicating with each other over a distance. It has always been a challenge to keep the message secret, especially when the communication can be intercepted by others on its way. It can be catastrophic if sensitive messages fall into the wrong hands. As the saying 'Necessity is the mother of invention' goes, we have always come up with innovative ideas to send messages in such a way that unintended recipients would find the messages useless even if they get access to them. Ciphers are good examples of this. But almost all the time, we have come up with even more innovative ideas to break such attempts to keep the secrecy as well. In the age of computers and internet, it is an obvious question - how to keep our communications secure? Let us take a look at https, the de-facto standard in keeping web communication secure.
What is https?
Simply put, https is secure http. The 's' in 'https' stands for 'secured'. When a website is accessed over https, it essentially means that the communication is encrypted and hence secure.
But, is that enough? Does this mean you are all set in terms of security? Besides, is that all about https? Let us find out.
Why https?
A few reasons why https is used:
Privacy and Integrity: When the communication channel is protected by encryption, the messages sent over that channel is not comprehensible to others who could be sniffing over the channel - thereby safeguarding our privacy. This means that https prevents 'Man-in-the-middle' attacks by making it impossible to hide any changes made to the message - thereby keeping intact the integrity of the data sent over the channel.
Authenticity: This is an interesting aspect of https websites. An authentic website means, when a website claims that it belongs to someone, we can safely assume that it belongs to them only. Still, just being https does not make it fully authentic. More about this later.
How is https made possible?
A browser uses the http protocol which sits over TCP/IP protocol to access a website. The http protocol itself is a 7 layered protocol, where the data is there in the Application layer. TLS (Transport Layer Security) works on this layer to make it secure. Confused? Let us expand on it.
Some background - Private Key and Public Key:
In cryptography, a pubic key/private key pair is used for asymmetric encryption - which means anything encrypted using a private key can be decrypted only using the corresponding pubic key and vice versa. Decryption cannot be done by the key used for encryption - hence the term asymmetric.
As the name suggests, public keys are public and are published over the internet. Anyone can use it to encrypt something which the owner alone can decrypt using their private key - in other words, make it 'For owner's eyes only'. Imagine the other way around - anything encrypted by the owner can be decrypted by anyone, but using the owner's public key only. Guess, we are getting a hang of what is the basis of the owner's claim that the website is theirs.
Now, let us take a look at what happens when a browser accesses a website:
1 - Browser connects to the website and asks for the certificate
2 - Website presents a certificate which is encrypted with the owner's private key
3 - Browser fetches the owner's public key and decrypts the certificate
4 - Browser validates the information with a Certificate Authority (More on this later)
5 - Browser and web server mutually agrees on a symmetric key for further communication using one of the handshake algorithms - mostly Diffie-Hellman (DH) Algorithm. This process is usually called the TLS handshake.
6 - http packet data are sent and received as encrypted using the mutually agreed upon symmetric encryption key.
FAQ: Why do we need another key for encryption/decryption, when we already have the public key - private key pair which could be directly used for encryption and decryption? The reason is that it is faster to use a smaller symmetric key compared to using a longer asymmetric key. Besides it is more sensible in the context to use a single use key which is valid only as long as the session is active.
Certificate Authority [CA]
Let us get back to the interesting topic of authenticity. One important reason for using https is that it ensures authenticity. If someone says they are xyz in their certificate, and the certificate decrypts correctly using xyz's public key, can we be sure that it is xyz? The catch is that anyone can say that they are xyz and create a certificate in their name. That is where a CA comes to the rescue.
A CA certifies that the public key indeed belongs to xyz. A certificate says it belongs to xyz and it contains the public key of xyz. Besides, the CA's own public keys are also embedded in the certificate to make it a certificate chain. Browsers use all this information to validate the authenticity of the certificate with the CA. Essentially, the CA signs the certificate.
But there is a catch here too - anyone can make a CA certificate as well. Such certificates are called self-signed certificates. In other words, the signing party is the CA there. If the browser is to approve of the authority of the CA, it should be a recognised CA. But the question remains - Is this another easy step? Can anyone register themselves as a CA and be recognised by the browsers? No. That is where it gets tricky for the malicious interceptors. And it is a relief. Know that it is a long process to register as a CA and get trusted by the browsers and operating systems. For this reason, there are only a handful of CAs out there. All this boils down to one thing for day to day usage - Use a trusted browser. And keep it updated.
Wrapping up
We saw what https is, the problem it tries to solve and how it works. The role of a third party certificate authority was also discussed.
Hope this message is useful and falls into the right hands :-). Cheers!!
Top comments (0)