Securing Communication: Part 1 - Encryption Protocols, HTTPS

Please subscribe to my substack newsletter https://ramkumarramasamy.substack.com/ if you like the content.

In our previous article - https://ramkumarramasamy.substack.com/p/the-journey-of-a-message-through, we saw how a message from the sender passes through various communication mediums to reach the receiver. This means that anyone intercepting the communication can read and alter the messages.

Now in this article, we will explore how to secure the communication. We will look at an example of what happens when you enter a URL in a browser and how it exchanges messages with an API on a web server through the HTTP protocol.

In HTTP, the messages exchanged between browser and server are transmitted in plain text. To prevent this, we can encrypt the messages with a key before sending them to the receiver. This process is known as encryption.

There are two types of encryptions - symmetric and asymmetric encryption.

Symmetric encryption

Symmetric encryption uses the same key to both encrypt and decrypt the message. The key has to be shared with the receiver before the communication begins.

But there is a problem with securely transferring the symmetric key. If the key is intercepted by untrusted parties or compromised, it can lead to security issues, allowing unauthorized users to decrypt the message.

Asymmetric encryption

To overcome the challenges in symmetric encryption, another mechanism called asymmetric encryption is introduced. It generates a pair of keys: a private key and a public key.

As the name implies, the private key is kept confidential and securely maintained, while the public key can be freely shared with anyone. When a message is encrypted with the public key, only the corresponding private key can decrypt it, and vice versa. This method ensures that even if the public key is widely distributed, the message can only be decrypted by the holder of the private key, thus avoiding the risks associated with key transfer in symmetric encryption.

There are two important properties of the public-private key pair, that work together to help with secure transmission as below:

1. Identity of the Sender: When a message is encrypted with a private key, and the receiver can decrypt it only with the corresponding public key, it confirms that the message was created by the original sender. This ensures that the message has not been tampered in the middle during message transmission.

2. Only the intended recipient has access - When a message is encrypted with a public key, only the intended recipient, who holds the corresponding private key, can decrypt it. This guarantees that only the recipient has access to the data, ensuring the confidentiality of the communication.

HTTPS

Now that we have covered the basics of private-public key pair and its properties, we can explore how it helps in securing the communication. Since HTTP, by default, transmits messages in plain text, it is often used with another protocol called TLS (Transport layer security).

TLS uses the principles of asymmetric encryption to establish a secure channel over an insecure network using a process known as SSL/TLS handshake. (SSL is just an older version of TLS).

When HTTP is combined with TLS, it becomes HTTPS (HTTP over TLS).

SSL/TLS handshake

When we enter the URL (such as google.com) in browser, the following steps will be executed before the actual communication begins.

1. Browser sends a "Client Hello" message to the server and initiates the communication process.
2. The server responds with a "Server Hello" message that includes its public key. Public key is not transferred as it is. We will discuss in detail on this step in our next article.
3. The client generates a new key, known as a session key, and encrypts it with the server's public key. This encrypted session key is then sent to the server.
4. Once the session key is received, the server decrypts the key using its private key, which only the server has. This process ensures that only the intended server can access the session key, establishing a secure communication channel for the data exchange.

Now, both the server and the client have the same session key. Messages are encrypted with this session key, and only this same session key can decrypt them, similar to symmetric encryption. This ensures that messages can safely travel between browser and server without being intercepted or tampered with.

HTTPS connection is established now, and a lock symbol will appear next to the domain name in the browser, as below. This lock symbol indicates that the connection is secure, providing users with confidence that their data is protected during transmission.

The above process still has a critical issue. During the initial step of the SSL/TLS handshake, when the client sends the "Client Hello" message, there is a vulnerability where a malicious server could intercept this message and respond with its own public key instead of the legitimate server's key.

This man-in-the-middle attack could lead the client into unknowingly establishing a connection with the malicious server instead of the intended one. As a result, the client might transmit sensitive information to the attacker, compromising the security of the communication.

In the next article, we can discuss how to overcome this security vulnerability.

Please like and subscribe to the article and drop comments to share your feedback.

Read the article in my substack link as well - https://ramkumarramasamy.substack.com/p/securing-networks-part-1-encryption