Is it safe to use HTTPS? What is the principle of HTTPS?

HTTPS

As the cost of building a HTTPS website decreases, most websites have begun to use the HTTPS protocol. Everyone knows that HTTPS is more secure than HTTP, and has heard of concepts related to the HTTPS protocol, such as SSL, asymmetric encryption, and CA certificates, but you may not be able to answer the following three soul-searching questions:

• Why is HTTPS secure?
• How is the underlying principle of HTTPS implemented?
• Is using HTTPS safe?

This article will go deeper and explain the security of HTTPS from the principle.

How HTTPS works

You may have heard that the reason why the HTTPS protocol is secure is that the HTTPS protocol encrypts the transmitted data, and the encryption process is implemented using asymmetric encryption. But in fact, HTTPS uses symmetric encryption for content transmission, and asymmetric encryption only works in the certificate verification stage.

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

① Certificate verification phase

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

② Data transmission stage

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

Why is symmetric encryption used for data transmission?

First, the encryption and decryption efficiency of asymmetric encryption is very low. In HTTP application scenarios, there is usually a lot of interaction between ends, so the efficiency of asymmetric encryption 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, so the content transmission encryption in HTTPS adopts symmetric encryption rather than asymmetric encryption.

Why do we need a CA to issue a certificate?

The HTTP protocol is considered unsafe because the transmission process can be easily intercepted and the server forged by eavesdroppers, while the HTTPS protocol mainly solves the security problem of network transmission.

First, let's assume that there is no certification authority and anyone can create a certificate. This brings about the classic "man-in-the-middle attack" problem. The specific process of the "man-in-the-middle attack" is as follows:

Process principle:

• 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 it with the public key of the middleman's certificate, and sends it to the middleman. The client then constructs symmetric encryption based on the random number to encrypt the transmission content.
• Because the middleman has the client's random number, he can decrypt the content through the symmetric encryption algorithm
• The middleman then sends a request to the regular website with the client's request content
• Because the communication process between the middleman and the server is legal, the legitimate website returns the encrypted data through the established secure channel.
• The middleman decrypts the content using the symmetric encryption algorithm established with the legitimate website
• The middleman encrypts the data returned by the regular content through the symmetric encryption algorithm established with the client.
• The client decrypts the returned result data using the symmetric encryption algorithm established with the middleman

Due to the lack of certificate verification, although the client initiates an HTTPS request, the client is completely unaware that its network has been intercepted and the transmission content has been completely stolen by the middleman.

How does the browser ensure the legitimacy of the CA certificate?

1. What information does the certificate contain?

• Issuing agency information
• Public Key
• Company Information
• domain name
• Validity
• fingerprint
• …

2. What is the legal basis of the certificate?

First of all, the authority must be certified. Not just any organization is qualified to issue certificates, otherwise it is not called an authority. In addition, the credibility of the certificate is based on the trust system. The authority needs to endorse the certificates it issues. As long as the certificate is generated by the authority, we consider it to be legal. Therefore, the authority will review the applicant's information. The requirements for the review of different levels of authority are also different, so certificates are divided into free, cheap and expensive.

3. How does the browser verify the legitimacy of the certificate?

When the browser initiates an HTTPS request, the server returns the website's SSL certificate. The browser needs to verify the certificate as follows:

• Verify that 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 source of the certificate is legitimate. Each issued certificate can find the corresponding root certificate based on the verification chain. The operating system and browser will store the root certificate of the authority locally. The local root certificate can be used to complete the source verification of the certificate issued by the corresponding institution;

• Determine whether the certificate has been tampered with. Need to verify with the CA server;
• Determine whether the certificate has been revoked. This is 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 considers the certificate to be legitimate only when any of the above steps are met.

Here is a question that I have been thinking 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 recognize that this certificate is legitimate. How can I avoid this kind of certificate impersonation? In fact, this is the use of public and private keys in non-encrypted symmetric encryption. Although the middleman can get 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 gets the certificate, he cannot disguise himself as a legitimate server because he cannot decrypt the encrypted data passed in by the client.

4. Can only certification authorities generate certificates?

If you want the browser not to prompt security risks, you can only use certificates issued by certification authorities. However, browsers usually only prompt security risks and do not restrict the website from being accessed, so technically anyone can generate a certificate, and as long as they have a certificate, they can complete the HTTPS transmission of the website. For example, the early 12306 used the form of manually installing private certificates to achieve HTTPS access.

What to do if the local random number is stolen?

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

In fact, HTTPS does not include security guarantees for random numbers. HTTPS only guarantees the security of the transmission process. Random numbers are stored locally, and local security belongs to another security category. Countermeasures include installing anti-virus software, anti-trojan software, and browser upgrades to fix vulnerabilities.

Will I be captured if I use HTTPS?

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

However, as mentioned above, the browser will only prompt security risks. If the user authorizes, the website can still be accessed and the request can be completed. Therefore, as long as the client is our own terminal, we can set up a middleman network with our authorization, and the packet capture tool is the proxy that acts as 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 the certificate. The packet capture tool then forwards the request to the server, and finally returns the result returned by the server to the terminal after outputting it in the console, thus completing the closed loop of the entire request.

Since HTTPS cannot prevent packet capture, what is the point of HTTPS? HTTPS can prevent the communication link from being monitored without the user's knowledge, but does not provide protection for active trusted packet capture operations, because in this scenario, the user is already aware of the risks. To prevent packet capture, it is necessary to adopt application-level security protection, such as using private symmetric encryption, and at the same time do a good job of anti-decompilation reinforcement on the mobile terminal to prevent the local algorithm from being cracked.

Summarize

The following is a brief Q&A summary of the full text:

Q: Why is HTTPS safe? A: Because HTTPS ensures transmission security, prevents the transmission process from being monitored and data from being stolen, and can confirm the authenticity of the website.

Q: What is the transmission process of HTTPS? A: The client initiates an HTTPS request, the server returns a certificate, the client verifies the certificate, and after verification, generates a random number locally for transforming the symmetric encryption algorithm. The random number is encrypted and transmitted to the server using the public key in the certificate. After receiving it, the server decrypts it using the private key to obtain the random number. Subsequent data interactions are encrypted and decrypted using the symmetric encryption algorithm.

Q: Why do we need a certificate? A: To prevent "man-in-the-middle" attacks and to provide identity proof for websites.

Q: Will I be captured when using HTTPS? A: Yes, I will be captured. HTTPS only prevents users from being monitored without knowing it. If users actively grant trust, a "middleman" network can be built, and the proxy software can decrypt the transmitted content.