HTTP is a clear text transmission, and there are three major risks: eavesdropping risk, tampering risk, and impersonation risk

Eavesdropping risk: Because HTTP clear text transmission, the middleman can easily obtain the communication content.

Tampering risk: The middleman can tamper with the information transmission content

Impersonation risk: The middleman can pretend to be a server communicating with the client, that is, a phishing website.

Secure communication needs to include: confidentiality, integrity, identity authentication and non-repudiation

Confidentiality: that is, the intermediary cannot obtain the true content of the communication

Integrity : The communication content will not be tampered with during the transmission process

Identity authentication: Confirm the true identity of both parties in the communication, and will not be impersonated by phishing websites

Non-repudiation: There is no denying the behavior that has occurred

HTTP transmits plain text, while HTTPS uses symmetric encryption to encrypt the transmitted messages. Symmetric encryption has the characteristics of fast encryption and decryption speed and high performance. HTTPS ensures that both communicating parties use the same key to encrypt the communication content to ensure the confidentiality of secure communication.

But how to obtain the key for symmetric encryption? If the Server transmits the key directly to the Client, the key will still be intercepted or even replaced by the middleman. As a result, the confidentiality and integrity of secure communication cannot be guaranteed.

Asymmetric encryption: Both encryption and decryption parties use different keys. One is used as a public key and can be made public; the other is used as a private key and cannot be made public. If you use public key encryption, you can only decrypt it with the private key; if you use private key encryption, you can only decrypt it with the public key.

For the Server, keep the private key and publish the public key to other Clients. For the Client, the symmetric key is encrypted with the public key and transmitted to the Client. The Client then decrypts the private key it retains to obtain the symmetric key. Then the communicating parties can encrypt the communication content through the symmetric key.

However, how does the Server securely transmit the public key to the Client? Directly transmitting the public key also risks being stolen or even dropped by a middleman.

In order to solve the trust problem of public key transmission, a third-party authority (Certificate Authority, referred to as CA) came into being. Server can apply for a certificate from the CA, attach the public key to the certificate, and then pass the certificate to the Client. When the Server applies for a certificate, it will submit information such as the DNS host name, and the CA will generate a certificate based on this information.

However, if the certificate is tampered with and the Client obtains a fake certificate, there will also be risks.

1. First use a digest algorithm (such as MD5, etc.) to generate a digest of the plain text content of the certificate, and then use the CA's private key to asymmetrically encrypt the digest (the private key is not used directly to encrypt the plain text content here). Encryption is because using asymmetric encryption is very time-consuming, so first compress the plaintext content into a much smaller fixed-length string, and then encrypt it with the private key. The public key decryption will be much faster)

2. After the Client obtains the certificate, it first uses the same digest algorithm to generate a digest of the plain text content. The transmitted encrypted digest is then decrypted by the CA's public key to obtain the transmitted digest. By comparing the two abstracts, you can determine whether the certificate content has been modified.

CA private key encryption and Client public key decryption are used here to ensure the security of identity authentication. Because only the CA private key is encrypted, the Client can successfully decrypt the public key.

After the Server passes the certificate to the Client, the Client signature verification process:

Note that there are two public keys here: one is attached to the certificate, the public key of the site, use symmetric keys for encryption; one is the CA's public key, which is used to decrypt the certificate's signature.

So, how is the public key of the CA transmitted here? In fact, this public key exists in the CA certificate, and this certificate (also called the Root CA certificate) is trusted by the operating system and is built-in to the operating system. There is no transmission process. In this way, the server transmits the certificate issued by the CA, and after receiving the certificate, the client can use the public key in the built-in CA certificate to decrypt the signature.

There is no longer the risk of the CA public key being compromised.

Both normal sites and intermediaries can apply for certificates from the CA, and the certificates applied for are all legal. So what if the middleman replaces the certificate transmitted from the Server to the Client with the middleman's own certificate during the transmission process?

In fact, this operation is not feasible, because to verify whether the certificate is legal, the Client must not only verify the signature to ensure that the certificate has not been tampered with, but also verify the domain name on the certificate and the one it requested. Are the domain names consistent? If the Client finds that the domain name is inconsistent, the verification will also fail.

However, if the Client trusts some illegal third-party organizations (called Charles) at the beginning and installs Charles' certificate, then the middleman can package the certificate passed by the Server to the Client into his own Certificate, because the certificate at this time is not applied to the CA, Charles can independently modify the domain name and other information on the certificate. After the Client obtains this certificate, it can use the public key of the Charles certificate to verify the signature, and the verification passes, and then sends the symmetric key to the middleman, as shown below:

Therefore, the middleman can capture the HTTPS package The premise is that the client trusts the illegal CA certificate, and the client actually communicates with the middleman by replacing the certificate. Therefore, we must not trust third-party certificates casually to avoid security risks.