After reading this article, my grandma understands the principle of HTTPS

Anyone who has surfed the Internet knows that the Internet is very unsafe. In particular, there are many free WiFis in public places, which may just be bait for attackers. There are also the master keys that everyone likes to use, etc.

The Problem with HTTP

So what risks might we encounter when we surf the Internet?

• Leakage, personal privacy, account passwords and other information may be stolen.
• Tampering: the received data may have been modified by a third party or have advertisements implanted into it, etc.
• Impersonation, the site visited is not the target server site, such as domain name spoofing, domain name hijacking, phishing website, etc.

Maybe the guy who lives next door to you, who wears flip-flops and speaks shyly, starts spying on your every move in the dead of night!

​​

Why can others obtain your online data? Friends who have a certain network foundation have some understanding of TCP/IP, have memorized various handshakes and waves, and are familiar with the HTTP protocol.

HTTP is an application layer protocol, located at the top layer of the TCP/IP reference model. User data is encapsulated through the application layer, transport layer, network layer, and link layer, and then sent to the target machine through the physical layer.

In these layers, the data is not encrypted, so once someone obtains your data packet, they can easily obtain the data information.

In order to protect data privacy and prevent data from being "naked", it is necessary to encrypt the data to be transmitted.

At present, encryption algorithms can be divided into two categories, one is symmetric encryption algorithm, and the other is asymmetric encryption algorithm.

Symmetric encryption

Symmetric encryption algorithms use the same key for both encryption and decryption. Under certain conditions, symmetric encryption can solve the problem of data transmission security.

For example, when I log in to a website, I need to fill in my account name and password to log in. The client symmetrically encrypts the login form information before transmitting it. At this time, even if Xiao Wang intercepts the data packet, he cannot obtain the content of the data because the data has been encrypted.

But the server is also confused after receiving the data. The server does not know the decryption key for the encrypted data packet you sent!

​​

Should the client and server negotiate the key before communicating? The client can notify the server that data transmission needs to be started, and then the server tells the client that we will use the key xxxx for encryption and decryption in the future!

​​

In this way, the content can be transmitted encrypted, but the first step of negotiating the key in the above figure also has security issues!

If Xiao Wang intercepts the data of the negotiated key, then the subsequent encrypted transmission data is no different from unencrypted for Xiao Wang! Therefore, symmetric encryption has the problem of key negotiation!

Asymmetric encryption

Based on the problems of symmetric encryption, asymmetric encryption was developed. Asymmetric encryption algorithms require a set of key pairs, namely public key and private key, and these two keys appear in pairs.

The content encrypted by the public key needs to be decrypted by the private key, and the content encrypted by the private key needs to be decrypted by the public key! The private key is saved by the server itself, and the public key is sent to the client.

After the client obtains the public key, it can encrypt the request and send it to the server. At this time, even if it is intercepted by Xiao Wang, Xiao Wang cannot decrypt the sent content without the private key, thus ensuring the "security" of the data sent by the client to the server!

However, since the public key also needs to be sent to the client through the network, it can also be intercepted by Xiao Wang. In this way, the content encrypted by the server private key can still be intercepted and decrypted by Xiao Wang, and the efficiency of asymmetric encryption is very low.

Both symmetric encryption and asymmetric encryption have the problem of key transmission, but at least asymmetric encryption can ensure that the content transmitted by the client to the server cannot be "cracked", and the performance of symmetric encryption algorithms is better, so can we do this?

During the first communication, the server sends the public key to the client, and the client generates a symmetric key, which is encrypted with the server's public key and sent to the server. All subsequent interactions are encrypted and transmitted using the symmetric key.

That is to say, the symmetric key is first encrypted with the asymmetric key, and then the actual requested content is encrypted with the symmetric key.

​​

The above solution seems perfect. After Xiao Wang gets the data, he seems to have no idea where to start. But is it really perfect?

Let’s look at the following picture:

​​

That is to say, Xiao Wang can pretend to be a server and communicate with the client. It is like there is an extra middleman between you and the server! That is to say, there are still loopholes in the process of negotiating the key!

My head hurts! Can I still surf the Internet safely? Is there no safer mechanism? In the process of negotiating the key, how can the client determine that the other party is the real target server? How to prove the identity of the server? Let's first understand digital certificates!

Digital Certificates

We have all kinds of certificates in our lives, including identity cards that can prove that we are a person with identity, and graduation certificates that can prove that we have studied for several years.

These certificates are certified by certain authoritative agencies, cannot be forged, and are credentials that can prove one's identity.

Then can the server also have something like an ID card to prove that it is indeed the target server and not forged by Xiao Wang when communicating with the server?

In life, these certificates are real and can be seen and touched, while the certificates in computers are virtual, visible but not tangible, and are recorded in the form of data, so they are called digital certificates!

When the client communicates with the server for the first time, the server needs to present its digital certificate to prove its identity and its public key, similar to the following (actually it is just a bunch of data, for the sake of intuitiveness):

​​

So how is this digital certificate generated? It can't be that the server creates one itself, right? As mentioned above, the certificates in our lives are issued by authoritative organizations and cannot be forged.

For example, ID cards are issued by police stations, and graduation certificates are issued by the Ministry of Education. If you need to verify the authenticity, you only need to enter the number in the relevant system to check it! Then our digital certificates should also have these two features: issued by an authoritative organization and anti-counterfeiting!

CA

The CA organization is the authority for issuing digital certificates, responsible for issuing certificates and verifying the legitimacy of certificates.

If the server needs to be an identity server, you need to submit an application to the CA organization. Of course, it is easier to get things done with money, and you can only get a certificate if you pay money...

The server submits an application to the CA, which requires the site information such as domain name, company name, public key, etc. After the CA approves it, it can issue a certificate to the server!

After the client obtains the server's certificate, it needs to verify whether the certificate number can be found in the corresponding CA organization, and check the basic information of the certificate, such as whether the domain name on the certificate is consistent with the currently accessed domain name, etc. It can also obtain the server's public key information in the certificate for negotiating symmetric keys!

The certificate has been issued, but how to prevent forgery and ensure that it is not tampered with during transmission? What if Xiao Wang intercepts the digital certificate and changes the public key to his own, then security is still not guaranteed? This requires a digital signature!

Digital Signature

Friends who have signed a labor contract with a company should know that when filling in the contract information, no erasures can be made, otherwise it will need to be filled in again! And at the end, Party A and Party B need to sign and stamp.

Once a contract is signed and sealed, it has legal effect and cannot be modified. Signing and sealing is to prevent the contract from being forged, and stipulating that it cannot be modified prevents the contract from being tampered with!

In real life, signing and stamping are real actions that act on a specific object!

But our digital certificate itself is virtual. How do we sign and seal a virtual certificate? What is the mechanism of digital signature?

When we are doing the permission system, when storing user passwords, we will calculate the MD5 digest before storing them. When logging in, we will calculate the MD5 digest of the password filled in by the user and compare it with the digest stored in the database. If they are consistent, the password is correct, otherwise the login fails!

MD5 is irreversible, and the digests calculated for different data are different (of course there is also a very small probability of hash collision). Based on this feature, the idea of ​​digital signature was born.

The server submits its basic information to apply to the CA. When the CA issues a certificate to the server, it will send it to the server together with the digital certificate and the summary calculated based on the certificate. This summary needs to be encrypted by the CA's own private key.

The application process is as follows:

​​

What? Not intuitive enough? Let’s give it a more intuitive view! From the picture below, we can see that the certificate issued by the CA to the server has its own exclusive “official seal”.

​​

Which CA organizations are authoritative or recognized by the client? When we open the IE browser, we can see the information of the CA organization built into the client, including the CA's public key, signature algorithm, validity period, etc.

​​

When the server communicates with the client, it will present the digital certificate and digital signature to the client.

After the client obtains the digital certificate and digital signature, it first finds the public key of the corresponding CA organization through the operating system or the built-in trusted CA organization in the browser to decrypt the digital signature, and then uses the same digest algorithm to calculate the digest of the digital certificate.

If the digest you calculated is consistent with the digest sent by the server, the certificate has not been tampered with!

This prevents tampering! A third party cannot get the private key of the CA organization, so it cannot encrypt the summary. If the signature is forged by a third party, it cannot be decrypted on the client side, which prevents forgery!

Therefore, digital signatures use this mechanism to ensure that digital certificates are not tampered with or forged. The specific process is as follows:

​​

What? Not intuitive enough? Then let's continue...

​​

One thing to note here is that one is the public key of the CA organization, which is built into the client and is used to decrypt the digital signature! The other is the public key of the target server, which is in the digital certificate content and is used to negotiate the symmetric key!

HTTPS

The title of this article is HTTPS, but so far there is no mention of HTTPS! In fact, HTTPS=HTTP+SSL, adding an SSL/TLS layer between the HTTP layer and TCP.

As shown below:

​​

SSL (Secure Sockets Layer) is called "Secure Sockets Layer" in Chinese. Later, due to its wide application, SSL was renamed TLS (Transport Layer Security) after standardization.

HTTPS uses the above-mentioned methods to solve the problems of data leakage, tampering, and counterfeiting that may exist on the network, ensuring the security of network transmission!

Do you understand the principle of HTTPS after reading this? Anyway, my grandma already understands it after reading it!

Author: Su Jing

Introduction: I have many years of experience in the development of large-scale Internet projects, and have in-depth research and relevant practical experience in high concurrency, distribution, and microservice technologies. I have experienced self-study and am keen on technology research and sharing! Motto: Always maintain an open-minded attitude to learn!

​​