Unveiling the Secrets of Secure Data Transmission
In our previous discussions, we talked about how computers share data and the connections they create. But here's the catch: the protocol we used had a problem. So, what's the issue, and how can we fix it? In this blog, we'll find out. We'll also discover a better protocol that makes our communication safer and smoother. let's get started.
The Previous Example
In our previous blogs, such as "Magic Doors," we used the web address http://example.com as an example to illustrate how a client reaches a server through the HTTP protocol. We delved into the intricacies of TCP connections, exploring the types of data transmitted during the TCP cycle. These discussions provided fundamental insights into networking and how information is transferred across the internet, bridging the gap from one location to another.
The issue we encounter with the HTTP protocol is that the data transmitted throughout the TCP lifecycle isn't secure. In simpler terms, the information exchanged after establishing the TCP connection remains in plain text.
Now, let's illustrate this problem with an example to gain a better understanding.
The Actual Problem
Imagine you want to send a confidential image file to a friend or colleague over the internet, and you're using a website that uses the HTTP protocol (unsecured) for file uploads. In this scenario, if someone with malicious intent, often referred to as a hacker, can intercept the network traffic during the file transfer, they can potentially steal the data, including the image and any other information
When we use an HTTP connection, the data, including the image file and any other content, is transmitted in its raw, unencrypted form. This means that the image is sent exactly as it is, and any text-based data, such as passwords, is sent as plain text.
A hacker can intercept the network traffic between your computer and the server hosting the website. the hacker can access the confidential image file and potentially extract any sensitive information being transmitted, such as passwords, which are sent as plain text in the HTTP request.
The intercepted data, including the image and sensitive information, can then be stored or used by the hacker for malicious purposes. This could involve accessing confidential images or using stolen passwords to gain unauthorized access to accounts or systems.
The Solution
To protect the data transmitted over the internet and ensure its confidentiality and integrity, we should use HTTPS (Hypertext Transfer Protocol Secure), which is an extension of HTTP (Hypertext Transfer Protocol). HTTPS provides a secure and encrypted communication channel between your web browser (or client) and the web server.
let's delve deeper into how the HTTPS protocol addresses security challenges
Before delving into an in-depth understanding of the HTTPS protocol, it's good to first explore two fundamental types of encryption: asymmetric encryption and symmetric encryption.
Asymmetric Encryption:
Asymmetric encryption involves a pair of keys: a public key and a private key.
The public key is intended for widespread distribution and can be used by anyone to encrypt data or messages.
However, only the person or system possessing the private key can decrypt and access the encrypted message.
The owner of the private key must safeguard it securely.
Symmetric Encryption:
Symmetric encryption uses a single key for both encryption and decryption. This means that the same key is used to lock (encrypt) and unlock (decrypt) the data.
The HTTPS Enigma
In a previous discussion, we covered the concept that before data can be exchanged between two parties, such as a client and a server, they need to create a connection or establish a bridge. This connection, often referred to as a TCP connection, serves as the foundation for transmitting data between them.
now https comes into play
In contrast to HTTP, where data is transmitted once a TCP connection is established, HTTPS introduces an additional layer of security. HTTPS operates in two distinct phases before securely transmitting data. These two phases are specifically designed to ensure that the data is exchanged in a protected and confidential manner
Phase One:
After the successful connection establishment, the client sends a Hello message to the server to get the public key of the server and the server acknowledges and sends back the Hello message followed by the public certificate key to the client(will soon understand why the public key is needed).
At this point, the client is actively engaged in a thorough verification process of the CA-signed certificate, to confirm its authenticity and validity.
wait What is a CA-Signed certificate? and why it is needed
CA - Certificate Authority
Certificate Authorities are trusted organizations that issue digital certificates to verify the authenticity of websites, servers, and individuals in online communication. They are a critical component of internet security and play a vital role in establishing trust and encryption on the web.
the public key of a web server is typically signed by a trusted Certificate Authority (CA) before it is used.
This is then used by the server to send it to the client so that the browser/client can validate this public certificate and trust the server.
If the validation of the public key is failed then the communication is terminated by the client
Note: The browsers come with some pre-installed CA public keys.
We will see why this CA signing is needed after understanding the whole process.
Now on successful validation, The client creates a secret key encrypts this key using the server's public certificate key and sends it back to the server. Now the server who is the actual owner of the public key decrypts the secret key using the server's private certificate and stores the secret key in the server side.
This secret key is known as a session key.
The process that occurs between the establishment of a TCP connection and the actual transmission of data is referred to as the SSL/TLS handshake.
Upon close examination, it becomes evident that the process occurring here follows an asymmetric encryption approach. This is because the client encrypts the session key and transmits it to the server, which subsequently decrypts it using its private key.
From this point onward, data transmission between the client and server occurs in an encrypted manner. This means that any data transmitted by either party is encrypted using the session key. Since both parties possess the session key, they can decrypt the encrypted data sent by the other party. This is how communication in the HTTPS protocol is secured.
the entire data transmission process involves encryption by one party and decryption by the other party using the same key. This characteristic aligns with symmetric encryption, where a shared key is used for both encryption and decryption.
Now why does the browser first need to validate the server's public certificate key?
Let's consider a situation where CA signing is not implemented, and the browser does not validate the public key before using it.
In this scenario, the client obtains the public key and encrypts the session key with this public key. It then sends this encrypted session key back to the server. The server, upon receiving the encrypted session key, happily decrypts it and stores it for data transmission. Subsequently, data transmission commences.
However, there's a critical issue here. Both the client and server believe they are engaging in secure communication. But in reality, an unauthorized party, a hacker, has surreptitiously entered the TCP connection during the SSL/TLS handshake. This hacker obtains the public key of the server and begins impersonating the server to the client. The hacker intercepts and captures data from the client.
Simultaneously, the hacker communicates with the server on behalf of the client, thereby controlling the data transmission. Astonishingly, the client and server continue their interaction without any awareness of this intrusion, ultimately leading to data theft.
To mitigate the risks associated with unauthorized parties attempting to impersonate a server, the use of CA-signed certificates is indeed crucial for effective and secure communication.
In such a scenario, if a hacker tries to act on behalf of the server and injects a public key into the client, the client will attempt to validate it against the pre-installed trusted keys. However, the client will not be able to validate the public key because the key provided by the hacker is self-signed and not present in the client's list of trusted keys. Consequently, the client will declare the received key as invalid and terminate the connection.
Tip: If you are a bit confused just make re-read eventually you get it and try to implement the exact concepts.
Conclusion
HTTPS effectively resolves security issues linked to plain HTTP by employing encryption to maintain confidentiality, verifying the server to establish trust, ensuring data integrity, defending against MitM threats, and fostering secure key management practices. These features collectively position HTTPS as the industry standard for secure internet communication, crucial for preserving user privacy and data security online.