Deep Dive : Fundamentals of HTTP/HTTPS, SSL/TLS and Encryption

In this article we will explore more on the Security aspects of your application . We will explore the industry security standards and how it can help you keep your client data secure as it is transferred over the network. This is not by any means a networking deep dive but to explore these concepts from the perspective of an application developer.

TABLE OF CONTENTS:

1. Why Secure?!!
2. Encryption
3. Symmetric vs Asymmetric Encryption
4. Certificates – TLS
5. Terminologies and Jargons
6. Conclusion

Why Secure?!!

Without secure connectivity , if data is transferred over the network it is vulnerable to malicious attacks which will compromise the data and in turn lead to drastic consequences.

As shown below, when you try to login to an online banking website which is not secure, your credentials are sent over as plain text through the network. A hacker who has broken into your network can easily get the credentials and compromise the account.

Encryption:

In simple terms, Encryption is basically scrambling any text (username and password in the above example) using an algorithm before sending it through the network. It becomes unrecognizable and can be decrypted by the intended user. Symmetric and Asymmetric encryption are the two types of encryption available to send data over a network.

Symmetric Encryption:

This type of encryption uses a key to encrypt the plain text. Once encrypted the text can be decrypted only using the same key. It is very quick and lightweight but there is one drawback when using this type of encryption over the network. Can you guess what?

That’s right the flaw is that the key also has to be sent over the network in order for the intended user to decrypt your encrypted text which again is less secure if the hacker gets their hands on the key.

So we have a very efficient quick and lightweight encryption algorithm but how do we get the symmetric key safely to the intended user over the network?

Asymmetric Encryption:

To overcome the limitations of symmetric encryption and to make it more secure, this type of encryption uses a pair of keys to encrypt and decrypt the text.

These keys are called public and private keys. Anything encrypted with a public key can only be decrypted with the private key. The idea is that anyone with access to the public key can encrypt data and send it over the network but even if the hacker gets the public key and the encrypted text there is no way to decrypt it without the private key. The private key is securely kept in the server and never sent over a network.

Here is how it works:

1. Client requests data from the server and server sends the public key.
2. Hacker has a copy of the key sent over the network.
3. Client encrypts the symmetric key with the public key and sends it to the server along with the symmetric key.
4. Server decrypts the data using the private key and gets hold of the symmetric key.
5. Hacker has the encrypted messages but cannot decrypt them now.

Asymmetric encryption although very secure, is not as lightweight or as fast as its symmetric counterpart. So the industry standard is to use asymmetric encryption to establish a secure session and then use symmetric encryption to transfer data within the secured session.

But wait, what if the hacker who is in the network routes all traffic from the original banking website and tricks the user into entering the credentials in their malicious and similar looking fake website.

Here is how it will work:

1. Hacker gets control of the network and routes all traffic into their malicious website.
2. User enters credentials and hacker uses his own public-private key pair through which he can easily decrypt your encrypted data and the account is compromised . (Evil laughs…)

Could there be a way for the clients and browsers to differentiate the actual bank website and the malicious website? This is where SSL(Secure Sockets Layer)/TLS(transport Layer Security) comes into the picture.

SSL/TLS:

SSL is the encryption protocol used when communication happens over a network which involves a combination of both symmetric and asymmetric encryption as discussed earlier. TLS is the modern version of SSL and in fact SSL has been deprecated. Although the term SSL has caught up and is being used interchangeably with TLS.

Website owners are obliged to use SSL/TLS protocols to keep the client data secure over the network. But in order to get to use SSL/TLS protocol the website owner needs an SSL/TLS certificate.

TLS certificates, once installed can be used as a way to differentiate legitimate websites from malicious ones.

TLS CERTIFICATES:

In asymmetric encryption we first send out the public key before establishing a secure session. Now the general practice is that a TLS certificate should also be sent along with the public key in order to prove to clients that this is a trusted website.

How to create a TLS certificate?

We could use openssl to create a certificate or we could use keytool for java based applications. Assume that we have created a certificate how do we make sure the clients or browsers believe this is a legitimate website?

This is done by signing the certificate. We could sign our own certificate but no one is going to trust a certificate signed by yourself right? This is where Certificate Authorities (CA) come in to the picture.

You create a CSR(Certificate Signing Request) to recognized third party CA’s like Symantec , Digicert etc. who will in turn validate your website and certificate and then sign them if they believe this is not fraudulent.

If a hacker tries to get their certificate verified using a CA, they are likely to get rejected. But what if the hacker gets a fake CA to sign his certificate ?

This is where your browser plays an important role in differentiating a valid CA from an invalid CA. Most of the valid CA’s public keys/ certificates are preloaded into the browser as shown below .

TLS certificates preloaded in browser

The moment it recognizes a website that is not signed by one of the known CA’s it put’s out a warning as shown below:

That’s it for this article and hope you got a good understanding of these concepts. In case you want to know more about the keytool commands used to generate and sign a certificate, here is a follow-up article on Securing your Spring Boot application with SSL/TLS.

References:

https://www.f5.com/glossary/ssl-tls-encryption

Advertisement