preface

In recent years, major companies pay more and more attention to the security of information transmission, and gradually upgrade the website to HTTPS, so you know what the principle of HTTPS is, exactly how it is to ensure the security of information transmission? There are a lot of introductions to HTTPS on the Internet, but I find that there are always more or less some omissions and omissions. Today, I will try to explain HTTPS from simple to profound. I believe that you will be able to grasp the principle of HTTPS after reading it.

1. Why is HTTP not secure
2. Four principles of secure communication
3. Description of HTTPS communication principles
   • Symmetric encryption
   • The digital certificate
   • Asymmetric encryption
   • A digital signature
4. Other HTTPS related questions

Why is HTTP not secure

Because HTTP is a plaintext transmission, there are three main risks

1. Risk of wiretapping

The middleman can obtain the communication content, because the content is clear text, so security risks after obtaining the clear text

2. Risk of tampering

The middleman can tamper with the packet content and then send the packet to the peer party, which is extremely risky

3. Risk of impersonation

Say you think you’re communicating with a treasure, but you’re actually communicating with a phishing site.

HTTPS is clearly designed to address these three risks, so let’s take a look at what HTTPS solves.

Four principles of secure communication

From the previous section, you can guess that HTTPS is designed to address these three risks. Generally speaking, secure communication needs to include the following four principles: confidentiality, integrity, authentication, and non-repudiation

1. Confidentiality: that is, encryption of data solves the risk of eavesdropping, because even if the middleman eavesdrops, because the data is encrypted, he cannot get clear text
2. Integrity: The data is not tampered with in the transmission process, no more, no less, and remain unchanged. If even a punctuation mark is changed in the process, the receiver can recognize it and never judge the received message as illegal
3. Identity authentication: confirm the true identity of the other party, that is, to prove that “your mother is your mother”, so as to solve the risk of impersonation, users do not have to worry about visiting a treasure results in communication with phishing websites
4. Undeniable: it is undeniable that the behavior has occurred, such as Xiao Ming borrowed 1000 yuan from Xiao Hong, but did not hit iOU, or hit iOU but did not sign, will cause the capital loss of Xiao Hong

Let’s take a step-by-step look at how HTTPS is implemented to satisfy the four principles of secure communication.

Description of HTTPS communication principles

Symmetric encryption: The final encryption form of HTTPS

Since HTTP is transmitted in plaintext, it is not enough for us to encrypt the packets. Since we want to encrypt the packets, we must need the communication parties to negotiate the key. One way is that the communication parties use the same key, that is, symmetric encryption to encrypt and decrypt the packets.

As shown in the figure, the two parties using symmetric encryption use the same key for encryption and decryption.

Symmetric encryption has the characteristics of fast encryption and decryption and high performance. It is also the encryption form adopted by HTTPS. However, there is a key problem here. If the key is transmitted directly in the form of packets, the subsequent communication is actually running naked, because the key will be intercepted or even replaced by the middleman. In this way, the middleman can decrypt the packets with the intercepted key, or even replace the key to tamper with the packets.

Some people say that the encryption of the key is not over, but if the other party wants to decrypt the key or to pass the encryption key to the other party, it will still be intercepted by the middleman, so it seems that the direct transmission of the key no matter how can not get rid of the Russian doll problem, it is not feasible.

Asymmetric encryption: Resolves the transmission of unidirectional symmetric keys

Direct transmission key no matter from which end of the transfer from the analysis of the previous section is not possible, here we look at another encryption method: asymmetric encryption.

Asymmetric encryption means that the encryption and decryption parties use different keys. One is the public key and the other is the private key. Only the private key can decrypt the ciphertext encrypted by the public key, and only the public key can decrypt the content encrypted by the private key.

Note: private key encryption in fact this statement is not rigorous, exactly say private key encryption should be called private key signature, because private encryption information public key can be decrypted, and public key is open, anyone can get, decryption with public key is called check

In this case, for the server, keep the private key and release the public key to other clients, and the other clients only need to encrypt the symmetric encryption key to the server. In this way, because of the public key encryption, only the private key can be decrypted, while only the server has the private key. Therefore, the transmission from the client to the server is secure. After decryption, the server can obtain the symmetric encryption key. In this way, after exchanging the key, the symmetric encryption key can be used for communication.

How can the server safely transfer the public key to the client? If the public key is transmitted directly, there is also the risk of the middleman switching.

Digital certificate, solve the public key transfer trust problem

How to solve the problem of public key transmission? Find the answer from real life scenarios. When an employee is employed, the enterprise will generally require to provide a Certificate of educational background. Similarly, the server can apply for a certificate from a CA, attach the public key to the certificate, and then send the certificate to the client. The site administrator applies for a certificate from the CA. The CA generates a certificate based on the information, such as the DNS host name

In this way, when the client obtains the certificate, it can obtain the public key on the certificate and use the public key to encrypt the symmetric encryption key to the server. It seems perfect, but there are two problems to consider here

Question 1. How to verify the authenticity of the certificate and prevent the certificate from being tampered with

Imagine the degree we mentioned above, how the enterprise determines whether the diploma you provide is true or false, the answer is to use the diploma number, after the enterprise gets the certificate, it will know the authenticity of the certificate by checking the diploma number on the Internet. The diploma number is actually the digital signature we often say, which can prevent certificate fraud.

Going back to HTTPS, how can the digital signature of a certificate be generated? A picture is worth a thousand words

The steps are as follows: 1. Use some digest algorithms (such as MD5) to generate a digest in plain text (such as the certificate serial number and DNS host name), and then use the private key of a third-party authority to encrypt (sign) the generated digest.

Rub up the message digest is arbitrary length of the input and generate pseudo random input of fixed length algorithm, no matter how long the input message, calculated the length of the message digest is fixed, in general, as long as the content is different, the inevitable different (the same probability can be thought of as close to zero), so you can validate the content is tampered with.

Why do you want to encrypt it as a digest, not directly?

Because of using asymmetric encryption is very time consuming, if the signature generated from the whole certificate content encryption, the client inspection attestation also need to decrypt the signature, certificate of plaintext is longer, the client attestation needs a long time, and with the words, will be to compress content long plaintext into much smaller fixed-length string, client attestation will be much faster.

2. The client uses the same digest algorithm to calculate the digest in plaintext of the Certificate after getting the Certificate, and the two can find out whether the message is tampered with with a single pair of the Certificate Authority (CA) private key. The middleman can replace the plain text of the certificate, and then replace the summary on the certificate after calculating the summary according to the summary algorithm on the certificate! In this case, when the client obtains the certificate, it finds that the summary is the same, and mistakenly thinks that the certificate is valid. Therefore, CA’s private key must be used to encrypt the abstract to generate the signature. In this way, the client uses CA’s public key to decrypt the signature and get the untampered and legitimate abstract (private key signature, public key decryption).

After the server sends the certificate to the client, the client performs the verification process as follows

In this way, since only the CA’s public key can decrypt the signature, if the client receives a fake certificate, it cannot decrypt using the CA’s public key. If the client receives a real certificate, but the content of the certificate is tampered with, and the summary comparison fails, the client will also consider the certificate as illegal.

You must have found the problem. How can the CA public key be securely transferred to the client? If the public key is transferred from the server to the client, the risk of the public key being transferred cannot be solved. In fact, the public key exists in the CA certificate, and the certificate (also known as Root CA certificate) is trusted by the operating system and built in the operating system. Therefore, there is no need to transfer the public key. You can open keychain to view many built-in trusted certificates.

The server transmits the certificate issued by the CA. After receiving the certificate, the client uses the public key in the built-in CA certificate to decrypt the signature and check the signature. In this way, the risk of public key transfer is solved.

Question 2. How do I prevent the certificate from being switched

Virtually any site can apply for a certificate from a third party authority, and middlemen are no exception.

Both the normal site and the middleman can apply for a certificate from the CA. The certificates obtained are valid because they are issued by the CA. In this case, can the middleman replace the certificate issued by the normal site with his own certificate during transmission

The answer is no, because in addition to verifying the validity of the certificate, the client also needs to verify whether the domain name on the certificate is consistent with the domain name requested by the client. Although the middleman can replace the legitimate certificate he applies to the CA, the domain name in the certificate is inconsistent with the domain name requested by the client. The client will consider it as a failure!

But the certificate swap above gives us an idea. What idea? So what do we need to do before we use Charles to grab HTTPS? Install Charles’s certificate

This certificate contains Charles’ public key, so Charles can transfer the certificate from server to client into his own certificate, and the client can use the Charles certificate you installed to check the certificate after getting it. Once authenticated, the public key in the Charles certificate is used to encrypt the symmetric key. The process is as follows

Therefore, Charles and other middlemen can capture HTTPS packets only if they trust their CA certificates, and then they can hide the whole thing by replacing the certificates. Therefore, we should not trust the certificates of third parties to avoid security risks.

Other HTTPS related questions

What is two-way authentication

In the process of the above description, we only verify the validity of the server transmission certificate on the client side, but how does the server verify the validity of the client, or use the certificate? When we transfer money online, think about whether we need to insert the U shield sent to us by the bank into the computer first? In fact, the U shield has a built-in certificate. During communication, the certificate is sent to the server. After the server passes the verification, communication can start. Voice-over: Identity authentication is only one of the functions of U shield. Other functions, such as encryption and decryption, are performed in U shield to ensure that the key does not appear in memory

What is a certificate trust chain

As mentioned above, we can apply for certificates from CA, but there are only a few top CA (Root CA) in the world. Many people apply for certificates from CA every day, and it is too busy to do anything. Delegate, he’s going to delegate to the CTO, the CFO, etc., so all you have to do is delegate to the CTO or whatever, and if the CTO is too busy, keep delegating.

Similarly, since the top CA is too busy, it can be authorized by the next level, so we just need to apply for the certificate from the level 1 / Level 2 / Level 3 CA. For example, the Root CA has no one to sign the certificate and the Root CA has no one to sign the certificate. The Root CA can only prove itself. This certificate is called a “self-signed certificate” or “root certificate”, and we must trust it, otherwise the chain of trust will not continue. (The root certificate, as mentioned earlier, is actually built into the operating system)

If the client receives a certificate from a secondary CA, the service sends the certificate trust chain to the client as well. The client then performs the following steps to verify the certificate:

1. The browser resolves the root certificate of the certificate chain using the trusted root certificate (root public key) to get the public key + digest check of the level 1 certificate
2. Decrypt the level-i certificate with the public key of the level-i certificate, and check the public key and summary of the level-2 certificate
3. Then take the public key of the secondary certificate to decrypt the secondary certificate sent by the server, and get the server’s public key and summary check, the verification process is over

conclusion

After reading this article, you should have a clear understanding of HTTPS principle. HTTPS is nothing more than HTTP + SSL/TLS

The SSL/TLS function is essentially how to negotiate a secure symmetric encryption key for subsequent communication. With this question in mind, I believe you can easily understand the two confusing meanings of digital certificates and digital signatures, and understand why HTTPS is encrypted. Charles, however, these tools can capture packets in plain text.

Shoulders of giants

• Juejin. Cn/post / 684490…
• Showme. Codes / 2017-02-20 /…
• Geek time, perspective HTTP protocol
• zhuanlan.zhihu.com/p/67199487

Finally, welcome everyone to pay attention to my official number, add my friend “Geekoftaste”, common progress