Understanding HTTPS and Its Encryption Principles

HTTPS (full name: Hypertext Transfer Protocol Secure, is a secure version of HTTP designed with security in mind. This article will delve into its principles.

The reason for using HTTPS is quite simple: it is due to the insecurity of HTTP.

When we send sensitive data to a server (such as your bank card or ID card), if we use HTTP for communication, the security cannot be guaranteed.

Firstly, during the transmission process, the data may be intercepted by a man-in-the-middle, leading to data theft.

Secondly, if the data is intercepted, the man-in-the-middle may modify or replace the data before sending it to the server.

Finally, when the server receives the data, it cannot determine whether the data has been modified or replaced, and of course, if the server cannot verify the source, it cannot confirm that the data truly comes from the client.

In summary, HTTP has three major drawbacks:

• Inability to ensure message confidentiality

• Inability to ensure message integrity and accuracy

• Inability to ensure the reliability of the message source

HTTPS was created to address these issues.

To resolve the issues present in HTTP, HTTPS employs encryption and decryption, digital certificates, and digital signatures. Below are the basic concepts of these technologies.

Symmetric and Asymmetric Encryption

To ensure message confidentiality, encryption and decryption are necessary.Currently, encryption algorithms are mainly divided into symmetric and asymmetric encryption.

1. Symmetric Encryption (Shared Key Encryption): The client and server share a key for encrypting and decrypting messages, which is known as symmetric encryption. The client and server agree on a key for encryption. Before sending a message, the client encrypts it using the key, and after sending it to the server, the server decrypts it using the same key.

The advantages of symmetric encryption:

• Symmetric encryption resolves the confidentiality issue of messages in HTTP.

The disadvantages of symmetric encryption:

• While symmetric encryption ensures message confidentiality, the shared key between the client and server makes it particularly vulnerable to leakage.

• Due to the high risk of key leakage, it is difficult to guarantee the reliability of the message source, as well as the integrity and accuracy of the message.

2. Asymmetric Encryption (Public Key Encryption): Since the shared key in symmetric encryption is easily leaked, we can use asymmetric encryption to solve this problem.

In asymmetric encryption, both the client and server have a public key and a private key. The public key can be exposed, while the private key is kept secret.

Messages encrypted with the public key can only be decrypted with the corresponding private key. Conversely, messages encrypted with the private key can only be decrypted with the public key. Thus, before sending a message, the client encrypts it using the server’s public key, and the server decrypts it using its private key upon receipt.

The advantages of asymmetric encryption:

• Asymmetric encryption uses a public key and a private key, addressing the confidentiality issue of messages in HTTP and reducing the risk of private key leakage.

• Since messages encrypted with the public key can only be decrypted with the corresponding private key, it greatly enhances the reliability of the message source, as well as the accuracy and integrity of the message.

The disadvantages of asymmetric encryption:

• Asymmetric encryption requires the recipient’s public key for message encryption, but the public key is not confidential and can be accessed by anyone, including a man-in-the-middle. The man-in-the-middle can do two things: firstly, they can replace the client’s public key with their own during the exchange with the server, so the server receives the wrong public key. The server cannot verify the source of the public key. Secondly, they can intercept the message sent by the client, modify it, and then encrypt it with the server’s public key before sending it to the server, resulting in the server receiving an incorrect message.

• The performance of asymmetric encryption is significantly slower than symmetric encryption, consuming more system resources. For this reason, HTTPS combines both encryption methods.

Digital Certificates and Digital Signatures

To address the insecurity of public key sources in asymmetric encryption, we can use digital certificates and digital signatures.

1. Application for Digital Certificates

In reality, there are specialized authoritative organizations that issue digital certificates, known as Certificate Authorities (CA).

We (the server) can apply for a digital certificate from these CAs.

The application process roughly involves:

First, generating a key pair locally, then taking the public key and other information (like the company name, etc.) to apply for a digital certificate from the CA.

Once the CA receives this information, it will use a one-way hash algorithm (like the commonly used MD5) to encrypt this information, resulting in a hash known as a digest.

One characteristic of a one-way hash algorithm is that it is irreversible; any change in the original content will result in a completely different encrypted output (though there is a small chance of collision, which those interested can look into the pigeonhole principle). This prevents the information from being tampered with.

After generating the digest, the CA will encrypt it with its private key, and the encrypted digest is referred to as a digital signature.

Finally, the CA will integrate our application information (including the server’s public key) with the digital signature to create the digital certificate, which is then sent back to us.

2. How Digital Certificates Work

Once the server obtains the digital certificate, it sends it to the client, which must use the CA’s public key to decrypt the digital certificate and verify its legitimacy. How do we obtain the CA’s public key? Our computers and browsers already have some root certificates from authoritative organizations built-in, which include the CA’s public key.

They are called root certificates because in real life, the certification centers are hierarchical, meaning there are top-level certification centers and various subordinate certification centers, forming a tree structure. The root certificates built into computers are from the highest-level organizations, but don’t worry; the public key of the root certificate is also applicable to the sub-levels.

The client uses the CA’s public key to decrypt the digital certificate. If successful, it indicates that the certificate is from a legitimate certification authority. After successful decryption, the client obtains the digest.

At this point, the client will generate a digest from the application information using the same hash algorithm as the CA and compare it with the decrypted one. If they match, it indicates that the content is complete and has not been tampered with. Finally, the client securely obtains the server’s public key from the certificate to engage in secure asymmetric encryption communication with the server. The server can also obtain the client’s public key in the same manner.

The following diagram illustrates the general process of applying for and using a certificate.

Through the learning above, we understand the characteristics and pros and cons of symmetric and asymmetric encryption, as well as the role of digital certificates.HTTPS does not rely on a single technology; instead, it integrates these technologies based on their characteristics to maximize performance and security.This integrated technology is known as SSL (Secure Socket Layer).Thus, HTTPS is not a new protocol; it merely adds a layer of encryption to HTTP.

Establishing HTTPS

Let’s first look at the flowchart of establishing HTTPS:

Here, the establishment of HTTPS is divided into 6 stages and 12 processes. Below, I will explain these 12 processes one by one:

1. The client begins SSL communication by sending a Client Hello message, which includes the client’s supported SSL version and a list of cipher suites (the encryption algorithms and key lengths used).

2. When the server is ready for SSL communication, it responds with a Server Hello message, which contains the SSL version and cipher suites, selected from the client’s list.

3. The server sends a certificate message that contains the public key certificate.

4. Finally, the server sends a Server Hello Done message to notify the client that the initial stage of SSL handshake negotiation is complete.

5. After the first SSL handshake concludes, the client responds with a Client Key Exchange message, which includes a random password string known as the Pre-master secret, encrypted with the public key from step 3.

6. The client then sends a Change Cipher Spec message, indicating that subsequent communication will be encrypted with the Pre-master secret.

7. The client sends a Finished message containing a verification value of all messages exchanged so far. The success of this handshake negotiation is determined by whether the server can correctly decrypt this message.

8. The server also sends a Change Cipher Spec message.

9. The server sends its own Finished message.

10. After the exchange of Finished messages between the server and client, the SSL connection is considered established. From this point, communication is protected by SSL, and application layer protocol communication begins, i.e., sending HTTP requests.

11. Application layer communication, i.e., sending HTTP responses.

12. Finally, the client disconnects, sending a close_notify message. After this, a TCP FIN message is sent to close the TCP communication.

Additionally, during the application layer data transmission, a Message Authentication Code (MAC) is appended to verify whether the message has been tampered with, ensuring message integrity.

Below, I will use a diagram to illustrate this, which is even more detailed than the previous digital certificate diagram (image source: “Illustrated HTTP”).

From the above introduction, we can see that HTTPS first uses digital certificates to ensure that the server’s public key reaches the client securely. It then uses asymmetric encryption to securely transmit the shared key, and finally uses the shared key to securely exchange data.

Although HTTPS is very secure, does that mean we should use HTTPS for communication in all scenarios? The answer is no.

1. While HTTPS provides a secure channel for message transmission, the encryption and decryption processes are resource-intensive. Therefore, unless in high-security scenarios, such as banking systems or e-commerce platforms, we must use HTTPS for communication. In other scenarios where security is not a high priority, HTTPS may not be necessary.

2. Using HTTPS requires a digital certificate, but digital certificates issued by authoritative organizations are generally not free and can be quite expensive. Thus, for personal websites, especially for students, if security is not a major concern, using HTTPS may not be necessary.

References

https://www.jianshu.com/p/4932cb1499bf

https://mp.weixin.qq.com/s/StqqafHePlBkWAPQZg3NrA

“Illustrated HTTP”

Source: Hollis

Edited by: Inoue Jun

Recent Popular Articles Top 10
↓ Click the title to view ↓
1. Falling into a Pit 10,000 Meters Deep
2. Once Upon a Time, a Student Was Late Because of Staying Up Late and Mistook a Math Problem for Homework
3. Atomic Bomb Manufacturing Guide
4. The Joy of Cat Petting
5. Why Is It Difficult to Create Bubbles When Washing Hair After a Long Time?
6. Can a Living Person Be Suffocated by Holding Urine?
7. So, Which Consumes More Power: WiFi or 4G?
8. A Note Was Found, and It Was Written…
9. Why Does the Top of a Pencil Easily Tear Paper?
10. Understanding Quantum Mechanics Through a Diagram (Schrodinger’s Cat)
Click here to view all past popular articles