Online interview experience: Is it absolutely safe to use HTTPS?

[[421374]]

This article is reprinted from the WeChat public account "Program New Vision", the author is Ershixiong. Please contact the WeChat public account "Program New Vision" to reprint this article.

A friend of mine was interviewed at Alibaba and was asked three questions about HTTPS. See if you can answer the previous three questions.

First, why is communication secure after using HTTPS?

Second, what is the principle of HTTPS to achieve communication security?

Third, is using HTTPS absolutely safe?

This article will talk about HTTPS and answer the above three questions.

About HTTPS

We have previously learned about the HTTP protocol's message format and interaction mode. We know that the content transmitted by HTTP is essentially text. HTTP/2 uses binary bytes for transmission, but it can still be decompiled. In other words, during the communication process, as long as the corresponding request is intercepted, the communication message information can be obtained. From this perspective, we say that the HTTP protocol is insecure.

HTTPS is HTTP wrapped in SSL, using SSL/TLS to establish a full channel and encrypt data packets. The main purpose of HTTPS is to provide identity authentication for website servers while protecting the privacy and integrity of exchanged data.

During the HTTPS communication process, both asymmetric encryption and symmetric encryption algorithms are involved, thus meeting the dual needs of performance and security.

Features of HTTPS

HTTPS transmits encrypted data, and it is difficult to obtain the plain text even if it is intercepted. HTTPS has the following characteristics:

• Content encryption: Using hybrid encryption technology (combining symmetric encryption and asymmetric encryption technology), middlemen cannot directly view the plaintext content;
• Verify identity: The client accesses its own server through certificate authentication;
• Protect data integrity: prevent the transmitted content from being impersonated or tampered with by middlemen;

Regarding these characteristics, we can analyze them step by step at the principle level.

HTTPS protocol implementation principle

The process of using HTTPS communication involves two parts: certificate verification and data transmission.

HTTPS Principles

The first stage, certificate acquisition and verification process:

• The browser initiates an HTTPS request;
• The server receives the request and returns an HTTPS certificate, which contains the public key information corresponding to the server's private key;
• The browser verifies whether the certificate is legitimate. If it is not legitimate (not certified by the CA or not trusted), it will prompt. It is usually located on the left side of the URL address in the browser.

The second stage, encryption key transmission and encrypted message transmission, can be collectively referred to as data transmission:

• If the certificate is verified to be legitimate or trustworthy, a random number is generated on the browser side, which is used for symmetric encryption of communication messages;
• Encrypt the random number using the public key and transmit it to the server;
• The server obtains the encrypted random number, decrypts it using the private key, and stores the random number. At this point, both parties have the symmetric encryption key (random number);
• The server uses the random number to symmetrically encrypt the data to be transmitted and returns the encrypted information to the client;
• The client obtains the encrypted data, uses the random number as the secret key, decrypts the message based on the symmetric encryption algorithm, and renders it to the user;

The implementation principle of HTTPS can be summarized in three steps:

• The client requests and verifies the public key from the server;
• The two parties negotiate to generate a "session key";
• Both parties use "session keys" for encrypted communication;

The first two steps are also called the "handshake phase".

The above process seems simple, but it will lead to several problems. Let’s look at them one by one.

How to ensure that the public key is not tampered with?

Solution: Put the public key in the digital certificate. As long as the certificate is credible, the public key is credible. This is why the server returns a certificate instead of a simple public key.

How to reduce the time consumption of public key encryption?

Solution: For each session, the client and server generate a "session key" to encrypt information. Since the "session key" is symmetric encryption, the operation speed is very fast, and the server public key is only used to encrypt the "session key" itself, which reduces the time consumed by encryption operations.

This is why a random number is generated during the HTTPS communication process. It is the "session key" and is used for symmetric encryption of data communications to improve algorithm performance.

In addition, a pair of public and private keys can only realize one-way encryption and decryption, so the content transmission encryption in HTTPS adopts symmetric encryption rather than asymmetric encryption.

After analyzing the entire HTTPS interaction process, we find that there is actually a loophole in the seemingly perfect solution: what if the data is swapped by the "middleman" during network transmission?

Man-in-the-middle attacks

Let's first look at what happens when the public key is swapped during communication based on HTTPS.

Man-in-the-middle attacks

In the above figure, the basic principle is that the middleman replaces the public key in the communication process with his own through network hijacking, and then pretends to be the server to communicate with the client, thereby stealing or tampering with the information.

We know that public and private keys and certificates can be generated by ourselves. Although an HTTPS request is initiated, if the certificate and public and private keys cannot be replaced, the security of the transmission cannot be guaranteed. At this time, the ultimate weapon is needed: SSL certificate purchase. It is also called CA certificate purchase.

CA Certificate

CA is the issuing authority of certificates. It is the core of Public Key Infrastructure (PKI). CA is responsible for issuing certificates, authenticating certificates, and managing issued certificates. Having such an authoritative organization to issue certificates ensures the credibility (legitimacy) of the certificates.

The browser will verify the SSL certificate returned by the server:

• Verify whether the domain name, validity period and other information are correct;
• Determine whether the source of the certificate is legal: 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;
• Determining whether the certificate has been revoked can be used in step 3 to reduce the interaction with the CA server and improve verification efficiency.

The certificate is legal only when the above conditions are fully met.

At this point, back to the issue of "man-in-the-middle" attacks, we will find that when the browser obtains a fake public key, it will find that it is illegal through comparison and verification, and then warn the user of the risk at the browser level. However, the browser will only warn of the risk, and the user can still authorize the trusted certificate to continue the operation.

Is using HTTPS absolutely safe?

Through the above learning, we already know that HTTPS communication is encrypted, and conventional packet capture methods cannot obtain the message content. However, in the case of the "man-in-the-middle" attack mentioned above, if you ignore the browser's security reminder and continue to visit subsequent web pages, security problems will arise.

With the authorization of the client, a middleman network can be established, and the packet capture tool is the proxy of the middleman. Usually, the HTTPS packet capture tool will generate a certificate (analogous to a fake certificate), which the user installs on the client or adds trust. At this time, the client first communicates with the packet capture tool, which then forwards the request to the server. The packet capture tool can process or output the information returned by the server and then return it to the client.

Therefore, the security of HTTPS is more reflected in the access performed without the user's knowledge. If the user is aware of it or actively grants credit, it means that the user has clearly understood the risks. At this time, if a man-in-the-middle attack occurs, HTTPS is still not safe.

Security of local random numbers

Finally, there is another aspect of security that we need to pay attention to, that is the security of local random numbers. Symmetric encryption is used when transmitting HTTPS content, so the secret key is stored on both the client and the server. As for the random numbers stored locally, HTTPS cannot guarantee their security. HTTPS focuses on the security during transmission.

In other words, local security belongs to another security category, and the corresponding measures include installing anti-virus software, anti-trojan software, browser upgrades to fix vulnerabilities, etc.

summary

Finally, let’s look at the three questions:

First, why is communication secure after using HTTPS?

HTTPS uses SSL/TLS to establish a full channel and encrypt data packets, ensuring transmission security, preventing the transmission process from being monitored and data from being stolen, and can confirm the authenticity of the website.

Second, what is the principle of HTTPS to achieve communication security?

HTTPS achieves secure communication mainly through a variety of encryption methods and identity authentication, which is mainly divided into three steps: (1) The client requests a certificate from the server and verifies the public key; (2) Both parties negotiate to generate a "conversation key"; (3) Both parties use the "conversation key" for encrypted communication;

Among them, the certificate ensures the credibility and security of the public key, the public key ensures the security of the transmission of the "conversation key", and the "conversation key" ensures the security of the communication message.

Third, is using HTTPS absolutely safe?

HTTPS focuses on the security during transmission. When a user visits a website without knowing it, the browser will give a security prompt. However, if the user continues to visit or set up trust, a "man-in-the-middle" attack may occur. In some countries where CA root certificates can be controlled, man-in-the-middle attacks are also feasible. Man-in-the-middle attacks often occur on public WIFs or routers.

HTTPS is also powerless in terms of local random number (secret key) security, and can only be protected by anti-virus software, vulnerability upgrades, etc. At the same time, HTTPS is almost ineffective in terms of hacker attacks, denial of service attacks, server hijacking, etc.