What is the difference between HTTP and HTTPS ? Interview Question

 The difference between HTTP and HTTPS

The main difference between HTTP and HTTPS is that the HTTP protocol transmits plain text data, while HTTPS transmits encrypted data, which means that HTTPS is more secure. It is also required by HTTPS to ensure security, so its performance is a bit worse than HTTP.

 Security alone is not enough. I intend to expand on how HTTPS solves security problems. There is no mechanism through this HTTPs, which reflects the difference between HTTPS and HTTP. Let us try to derive the process of HTTPS encryption. 

The derivation process does not involve complex implementation details:

How to transfer data safely?

If A and B want to communicate securely, what is considered secure communication? It is natural to think of: The data transferred between A and B can only be understood by A and B. Even if the intermediary intercepts the information but cannot understand it, it is considered safe.

The processing method of secure communication:

To allow A and B to understand, the data must be encrypted, and the first thing that comes to mind is symmetric encryption. Symmetric encryption means that A and B each hold the same key. When they transmit information, they will use the key to encrypt the information and decrypt the message at the end of the message to complete the secure communication.

In symmetric encryption, the choice of encryption algorithm will be involved. In the real world, it is usually a situation where multiple clients face one server. It is impossible to use the same encryption algorithm between each client and server. If this is the case, it is like no encryption. So, it is destined to use different encryption methods between each client and server.

How to use different encryption methods between each client and server?

If you want to use different encryption methods for different machines, the most direct idea is to use random numbers. In other words, the encryption algorithm is generated based on a random number every time between the client and the server. (To ensure randomness in a specific implementation, more than one random number is used)

This process of generating encryption algorithms is called negotiation. The problem now is that the negotiation process is transparent, which means that the middleman can intercept the negotiation process and know our encryption method. To solve this problem, we need to encrypt the negotiation process.

How to encrypt the negotiation process?

The reason why we can come to this step is that because we chose to use symmetric encryption at the beginning, which means that the symmetric encryption at the beginning caused the current problems, so we can no longer use symmetric encryption at this time otherwise, we will fall into an endless loop.

In the field of cryptography, there is another encryption process called asymmetric encryption. Its logic is as follows: one of the communication parties holds the private key, and the other holds the public key. The information encrypted by the private key can be decrypted by the public key. But the data encrypted by the public key can only be decrypted by the private key.

According to the rules of asymmetric encryption, we let the server hold the private key and let the client hold the public key. In this way, it can be ensured that the client is safe when sending messages to the server (on the contrary, it is not safe for the server to send messages to the client). We can arrange the important logic during the negotiation to send messages from the client to the server. Thereby ensuring the security of the negotiation process.

How does the client obtain the public key?

Now the asymmetric encryption algorithm is used to solve the security problem of the negotiation, but the premise of asymmetric encryption is that the client needs to obtain the public key. This is another problem. The client and the server do not know the identity of each other before interacting with the server. What about letting the client obtain the public key?

There are only two ways:

 The client asks the server for the public key. The client obtains the public key from a remote public server.

Method 2 is obviously not enough. Not to mention one more access node. How to find the address of the public server is also a problem to be solved, so I still use method 1.

But there is a problem in Method 1: What if the middleman modifies the public key sent by the server to the client? In other words, the client cannot know whether the server sending the public key is a real server.

Introducing a third-party organization to solve the problem.

The problem that the client cannot identify the server and the middleman is called the "identity verification" problem, which means that we need to encrypt the process of the server sending the public key to the client.

This is over. We previously chose asymmetric encryption due to the bottleneck of symmetric encryption, but now we have also encountered a bottleneck when using asymmetric encryption. Obviously, these two encryption methods are unavailable otherwise it will fall into an endless loop again.

 Next, we must solve this problem through the intervention of a third-party organization. First, we save the public key of the third-party authority, and then the third-party organization uses the private key to encrypt the public key that the server will send to the client. After the client receives the encrypted public key (digital certificate), it can Decrypt with the public key of a third-party organization that you keep.

 So far, we have explained the concepts of symmetric encryption, asymmetric encryption, CA, and digital certificates used in HTTPS, but there is still a concept called digital signature that has not been explained.

 In real life, the CA will issue certificates to our normal companies and issue certificates to the bad companies of the intermediary/broker. What if the intermediary subcontracts the issued certificates? At this time, we can still use the CA's private key to decrypt, but the certificate has been tuned.

So how does the client verify the authenticity of the certificate? The answer is that the certificate itself tells the client how to distinguish between genuine and counterfeit. For example, there is a certificate number on the certificate, and there is also a method of how to calculate the certificate number. The client can calculate the number of the certificate to be obtained according to the method of calculating the certificate number, and then compare this number with the number on the certificate, If the same proves that it has not been transferred.

The certificate number here refers to the digital signature, and the certificate refers to the digital certificate.

To summarize HTTPS: To ensure the security of communication between the client and the server, HTTPS must use an asymmetric encryption algorithm for encryption. The process of negotiating symmetric encryption algorithms is guaranteed by asymmetric encryption algorithms. In the asymmetric encryption algorithm, the process of obtaining the public key by the client requires a third-party organization (CA) to ensure security by issuing digital certificates.

In general, after asymmetric encryption algorithm is negotiated through this series of mechanisms, the client and the server can communicate securely through the algorithm.