Hello everyone, I am Lao Tian who specializes in sharing useful information with you. In addition, friends who need interview materials, remember to reply backstageInterview

##Preface

• Why is HTTPS safe?
• How to implement the underlying principle of HTTPS?
• #Is using HTTPS necessarily safe?

The implementation principle of HTTPS

But in fact, HTTPS uses symmetric encryption to encrypt content transmission, and asymmetric encryption only works in the certificate verification phase.

The overall process of HTTPS is divided into certificate verification and data transmission stages. The specific interaction process is as follows:

Certificate verification stage :

• The browser initiates an HTTPS request.
• The server returns the HTTPS certificate.
• The client verifies whether the certificate is legal and prompts an alarm if it is not legal.

Data transmission phase:

• When the certificate is verified to be legal, a random number is generated locally.
• Encrypt the random number through the public key and transmit the encrypted random number to the server.
• The server decrypts the random number through the private key.
• The server constructs a symmetric encryption algorithm through the random numbers passed in by the client, and encrypts the returned result content before transmitting it.

Why is symmetric encryption used for data transmission?

First of all, the encryption and decryption efficiency of asymmetric encryption is very low, and in HTTP application scenarios, there is usually a lot of interaction between ends, and asymmetric encryption The efficiency is unacceptable.

In addition, in the HTTPS scenario, only the server saves the private key, and a pair of public and private keys can only achieve one-way encryption and decryption. Therefore, the content transmission encryption in HTTPS adopts symmetric encryption instead of asymmetric encryption. encryption.

Why do we need a CA certification authority to issue a certificate?

The HTTP protocol is considered unsafe because the transmission process can easily be hooked by listeners to monitor and forge servers, while the HTTPS protocol mainly solves the security problem of network transmission. .

First of all, we assume that there is no certification authority and anyone can create a certificate. The security risk this brings is the classic "man-in-the-middle attack" problem.

The specific process of "man-in-the-middle attack" is as follows:

• Local requests are hijacked (such as DNS hijacking, etc.), and all requests are sent to the middleman's server.
• The middleman server returns the middleman's own certificate.
• The client creates a random number, encrypts the random number through the public key of the middleman certificate and transmits it to the middleman, and then uses the random number to construct symmetric encryption to encrypt the transmission content.
• Because the middleman has the client's random number, it can decrypt the content through a symmetric encryption algorithm.
• The middleman uses the client's request content to initiate a request to the regular website.
• Because the communication process between the middleman and the server is legal, the regular website returns encrypted data through the established secure channel.
• The middleman decrypts the content using a symmetric encryption algorithm established with the legitimate website.
• The middleman encrypts and transmits the data returned by the regular content through the symmetric encryption algorithm established with the client.
• The client decrypts the returned result data through the symmetric encryption algorithm established with the middleman.

What information does the certificate contain?

• Issuing authority information
• Public key
• ##Company information
• Domain name
• Validity period
• Fingerprint
• ......

What is the legal basis for the certificate?

How does the browser verify the validity of the certificate?

• Verify whether the domain name, validity period and other information are correct. The certificate contains this information, making it easier to complete the verification.
• Determine whether the certificate source is legal. Each issued certificate can find the corresponding root certificate according to the verification chain. The operating system and browser will store the root certificate of the authoritative organization locally. The local root certificate can be used to complete the source verification of the certificate issued by the corresponding organization.

• ** Determine whether the certificate has been tampered with. **Requires verification with CA server.

• #** Determine whether the certificate has been revoked. **Achieved through CRL (Certificate Revocation List) and OCSP (Online Certificate Status Protocol).

  OCSP can be used in step 3 to reduce interaction with the CA server and improve verification efficiency.

The browser will consider the certificate to be legitimate only if any of the above steps are met.

**Insert a question here that I have thought about for a long time but the answer is actually very simple: **Since the certificate is public, if I want to launch a man-in-the-middle attack, I download a certificate from the official website as my server certificate, then the client will definitely agree that this certificate is legitimate. How to avoid this kind of certificate fraud?

In fact, this is the use of public and private keys in non-encrypted symmetry. Although the middleman can obtain the certificate, the private key cannot be obtained.

It is impossible to deduce the corresponding private key from a public key. Even if the middleman obtains the certificate, it cannot pretend to be a legitimate server because it cannot decrypt the encrypted data passed in by the client.

Can only certification authorities generate certificates?

If you need the browser not to prompt for security risks, you can only use certificates issued by certification authorities.

But browsers usually only prompt for security risks and do not restrict the website from being accessible, so technically anyone can generate a certificate, and as long as there is a certificate, the HTTPS transmission of the website can be completed.

For example, the early 12306 used manual installation of private certificates to achieve HTTPS access.

What should I do if the local random number is stolen?

Certificate verification is implemented using asymmetric encryption, but the transmission process uses symmetric encryption, and the important random numbers in the symmetric encryption algorithm are locally generated and stored locally Yes, how does HTTPS ensure that the random number will not be stolen?

In fact, HTTPS does not include security guarantees for random numbers. HTTPS only guarantees the security of the transmission process, and the random numbers are stored locally. Local security belongs to another security category. The countermeasures include installing anti-virus software, Anti-Trojan horses, browser upgrades to fix vulnerabilities, etc.

Will the packet be captured if I use HTTPS?

HTTPS data is encrypted. Under normal circumstances, the packet content captured by the packet capture tool after proxy request is encrypted and cannot be viewed directly.

However, as mentioned above, the browser will only prompt the security risk. If the user authorizes it, he can still continue to access the website and complete the request.

Therefore, as long as the client is our own terminal and we authorize it, we can set up a middleman network, and the packet capture tool serves as the agent of the middleman.

Usually, the HTTPS packet capture tool is used to generate a certificate. The user needs to manually install the certificate into the client, and then all requests initiated by the terminal complete the interaction with the packet capture tool through this certificate.

Then the packet capture tool forwards the request to the server, and finally outputs the result returned by the server to the console and then returns it to the terminal, thereby completing the closed loop of the entire request.

Since HTTPS cannot prevent packet capture, what is the point of HTTPS? HTTPS can prevent users from being monitored on communication links without their knowledge. It does not provide protection for active credit-granting packet capture operations because users in this scenario are already aware of the risks.

To prevent packet capture, application-level security protection needs to be adopted, such as private symmetric encryption, and anti-decompilation reinforcement on the mobile terminal to prevent local algorithms from being cracked.

##Summary

Q: Why is HTTPS safe?

Q: What is the transmission process of HTTPS?

Q: Why do I need a certificate?

Q: Will packets be captured when using HTTPS?