Is it secure to use HTTPS and how does it work?

HTTPS With the decreasing cost of HTTPS, most websites are now using the HTTPS protocol. We all know that HTTPS is more secure than HTTP, and we have heard of concepts related to the HTTPS protocol such as SSL, asymmetric encryption, CA certificates, etc., but we may not be able to answer the following three soul-crushing questions. Why is HTTPS secure? How is the underlying principle of HTTPS implemented? Does using HTTPS necessarily mean that it is secure? In this article, we will go deeper and deeper to explain the security of HTTPS from the principle. The principle of HTTPS implementation You may have heard that the HTTPS protocol is secure because the HTTPS protocol encrypts the transmitted data, and the encryption process is implemented using asymmetric encryption. However, HTTPS actually uses symmetric encryption for the encryption of content transmission, and asymmetric encryption is only used for the certificate verification phase. The overall process of HTTPS is divided into certificate authentication and data transmission phases, and the specific interaction process is as follows. ① Certificate validation phase Browser initiates HTTPS request The server returns the HTTPS certificate The client verifies whether the certificate is legal, and prompts for an alarm if it is not. ② Data transmission stage When the certificate is verified as legitimate, generate random numbers locally Encrypt the random number by 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 incoming random numbers from the client and encrypts the returned result content for transmission. Why is symmetric encryption used for data transmission? First of all, the encryption and decryption efficiency of asymmetric encryption is very low, and in the http application scenario, there are usually a lot of end-to-end interactions, so the efficiency of asymmetric encryption is unacceptable. In addition, in the HTTPS scenario, only the server side keeps the private key, and 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 instead of asymmetric encryption. Why do I need a certificate issued by a CA certification authority? The HTTP protocol is considered insecure because the transmission process can be easily monitored by eavesdroppers and spoofed servers, while the HTTPS protocol mainly addresses the security of network transmission. First of all, we assume that there is no authentication authority, anyone can make a certificate, which brings the security risk is the classic "man-in-the-middle attack" problem. The specific process of "man-in-the-middle attack" is as follows. Process principle. Local requests are hijacked (such as DNS hijacking, etc.), all requests are sent to the man-in-the-middle server intermediary server to return the intermediary's own certificate The client creates a random number, encrypts the random number through the public key of the intermediary's certificate and sends it to the intermediary, then constructs a symmetric encryption with the random number to encrypt the transmission content The intermediary can decrypt the content by symmetric encryption algorithm because it has the random number from the client The intermediary sends a request to the regular website with the client's request content. Because the communication process between the intermediary and the server is legitimate, the legitimate website returns the encrypted data through the established secure channel. The intermediary decrypts the content with the symmetric encryption algorithm established with the legitimate website The intermediary 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 with the symmetric encryption algorithm established with the intermediary Due to the lack of certificate validation, the client is completely unaware that its network has been intercepted and that all the transmitted content has been stolen by the middleman, even though the client has initiated an HTTPS request. How does the browser ensure the legitimacy of the CA certificate? 1. What information does the certificate contain? Issuer information Public Key Company information Domain name Expiration date Fingerprint ...... 2. what is the basis for the legitimacy of the certificate? First of all, the authority must be certified, not just any organization is qualified to issue a certificate, otherwise it is not called an authority. In addition, the credibility of the certificate is based on the trust system, and the authority needs to endorse the credit of the certificate issued by it. Therefore, the authority will review the applicant's information, and different levels of authorities have different requirements for the review, so there are free, cheap and expensive certificates. 3. How does a browser verify the legitimacy of a certificate? When a browser initiates an HTTPS request, the server will return the SSL certificate for the website and the browser will need to verify the certificate as follows. Verify that the domain name, expiration date and other information is correct. The certificate contains this information, so it is relatively easy to complete the verification; Determine whether the certificate source is legitimate. Each issued certificate can be based on the verification chain to find the corresponding root certificate, the operating system, the browser will be stored in the local authority root certificate, the use of the local root certificate can be issued to the corresponding authority to complete the source verification; Determine whether the certificate has been tampered with. Requires verification with the CA server; Determine whether a certificate has been revoked. This is achieved through CRL (Certificate Revocation List) and OCSP (Online Certificate Status Protocol), where OCSP can be used in step 3 to reduce the interaction with the CA server and improve authentication efficiency. Any of the above steps are satisfied before the browser considers the certificate is legitimate. Here insert 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 and download a certificate on the official website as my server certificate, the client will definitely recognize the certificate as legitimate, how to avoid this certificate impersonation? In fact, this is the use of public and private keys in non-encryption symmetry. Although the middleman can get the certificate, the private key cannot be obtained, and it is impossible to derive the corresponding private key from a public key, and even if the middleman gets the certificate, it cannot be disguised as a legitimate server because it is impossible to decrypt the encrypted data coming from the client. 4. Can only the certification authority generate certificates? If you need a browser that does not indicate security risks, you can only use a certificate issued by a certification authority. However, browsers usually only indicate security risks and do not restrict access to websites, so technically anyone can generate a certificate, and as long as there is a certificate, the HTTPS transfer of the website can be completed. For example, the early 12306 is the manual installation of private certificates in the form of HTTPS access. What can I do if my local random number is stolen? Certificate authentication is achieved using asymmetric encryption, but the transmission process is symmetric encryption, and the important random number in the symmetric encryption algorithm is generated locally and stored locally, how can HTTPS guarantee 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, while the random numbers are stored locally, and the local security belongs to another security area, and the corresponding measures include installing anti-virus software, anti-Trojan horse, and upgrading browsers to fix vulnerabilities. Will I be caught if I use HTTPS? HTTPS data is encrypted, and the packet content captured by a packet capture tool after a regular proxy request is encrypted and cannot be viewed directly. However, as mentioned above, the browser will only indicate the security risk, and if the user authorizes it, he/she can still continue to access the website and complete the request. Therefore, as long as the client is our own terminal, we can set up a middleman network if we authorize it, and the packet capture tool is a proxy for the middleman. Usually the HTTPS packet-catching tool is used to generate a certificate, which the user needs to manually install into the client, and then all requests initiated by the terminal complete their interaction with the packet-catching tool through the certificate, and then the packet-catching tool 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 entire request closure. Since HTTPS cannot prevent packet capture, what is the point of HTTPS? HTTPS can prevent users from unknowingly listening to the communication link, but does not provide protection against active packet capture, because the user is already aware of the risk in this scenario. To prevent packet capture, application-level security protection is needed, such as private symmetric encryption, and mobile anti-compilation reinforcement to prevent local algorithms from being cracked. Conclusion The following is a short Q & A summary. Q: Why is HTTPS secure? A: Because HTTPS guarantees transmission security, prevents the transmission process from being listened to, prevents data from being stolen, and can confirm the authenticity of a website. Q: How does the HTTPS transmission process work? A: The client initiates the HTTPS request, the server returns the certificate, the client verifies the certificate, and after the verification is passed, the random number is generated locally to transform the symmetric encryption algorithm, the random number is encrypted by the public key in the certificate and transmitted to the server, the server receives it and decrypts the random number by the private key, and the subsequent data interaction is encrypted and decrypted by the symmetric encryption algorithm. The subsequent data interaction is encrypted and decrypted by the symmetric encryption algorithm. Q: Why do we need certificates? A: To prevent "man-in-the-middle" attacks and to provide identity proof for websites. Q: Will the use of HTTPS be caught? A: Yes, HTTPS only prevents users from listening to communications without their knowledge.