The service side guide | HTTPS project practical guide

This article focuses on several practical guidelines for HTTPS.

HTTPS Usage Analysis HTTPS Project Scenario HTTPS design reference HTTPS degrade attack

HTTP has no encryption mechanism. You can use SSL or TLS to encrypt HTTP communications. Therefore, HTTPS is the secure version of HTTP. The SSL layer is added to THE HTTP protocol and consists of two parts: HTTP and SSL. SSL is independent of HTTP and can be used with protocols such as WebSocket. Why use HTTPS HTTP has no encryption mechanism and communication is transmitted in plain text without any security processing. However, any corner of the Internet may be the communication content in the transmission process of interception, tampering, impersonation and other risks. Among them, any corner refers to the nodes that users’ communication content must pass through when it is transmitted between browser and server, such as WIFI hotspot, router, firewall, reverse proxy, cache server, etc. Therefore, the threat of HTTP communication is self-evident. Intermediaries can eavesdrop on privacy and leak sensitive information of users. Tamper with the web page, for example, intermediary inserts advertising content to the page, and even some intermediary traffic hijacking, for example, sometimes you will find that the domain name is not wrong, but the result is jumped to a phishing site, because the site is hijacked by the intermediary. Therefore, to address the risks of eavesdropping, tampering, and impersonation, HTTPS is of great value. HTTPS encrypts communication content so that third parties cannot eavesdrop. HTTPS can be used for identity authentication. Once the communication content is tampered, the communication parties will immediately discover it. In addition, HTTPS ensures the integrity of communication content and prevents communication content from being impersonated or tampered with. SSL and TLS HTTP encrypts HTTP communication using SSL or TLS. SSL was first initiated and developed by Netscape Communications, and the latest version is SSL 3.0. At present, it is led and managed by IETF. IETF developed TLS 1.0, TLS 1.1 and TLS 1.2 based on SSL 3.0. To better understand HTTPS, observe the communication procedure of HTTPS. In the first step, the user enters an HTTPS-enabled web address, such as blog.720ui.com, into the browser. An HTTPS request is made to establish a connection to the server over TCP, using port 443. In the second step, the server sends the certificate to the client, including the domain name, the company applying for the certificate, and the public key of the certificate. Third, the client parses the certificate using SSL or TLS to verify the validity of the public key, for example, the certification authority and expiration time. If the certificate is abnormal, a warning dialog box is displayed indicating that the certificate is faulty. If there is nothing wrong with the certificate, a key is generated and the encrypted key of the certificate’s public key is sent to the server. Fourth, the server decrypts with the certificate private key to obtain the key passed by the client. Fifth, the server sends the encrypted message to the client with the client’s key. In the sixth step, the client decrypts the information sent by the server with the key and verifies whether the information sent by the server can be decrypted with the key. Seventh, the client encrypts the request with the key and sends the communication to the server. In the sixth step, the server decrypts the request content with the key, encrypts the response content with the key after the service processing, and then sends the communication content to the client. In the preceding process, HTTPS combines the advantages of symmetric and asymmetric encryption algorithms. Symmetric encryption algorithm is used to encrypt communication content quickly, which makes up for the slow processing speed of asymmetric encryption algorithm and ensures the confidentiality of communication content. At the same time, the asymmetric encryption algorithm is used to encrypt the keys of the symmetric encryption algorithm to ensure the secure exchange of the keys of the symmetric encryption algorithm. Therefore, THE HTTPS protocol uses the asymmetric encryption algorithm to securely exchange keys. After establishing a communication connection, the SYMMETRIC encryption algorithm is used to ensure the confidentiality of the communication content. HTTPS Project Scenarios Real service scenarios are complex. Here, we organize the more complex application scenarios encountered in three projects. CDN acceleration for HTTPS Communication There are two methods for CDN acceleration for HTTPS communication. In scheme 1, the server (source site) provides a certificate to the CDN vendor, including the certificate public key and certificate private key. The CDN is responsible for content cache. If the CDN has cache, it directly responds to the CDN in HTTP or HTTPS format. This scheme is applicable only to the source station that needs to prevent hijacking and tampering and is willing to provide certificate to CDN. In scheme 2, the server (source site) does not provide a certificate to the CDN vendor. Therefore, the CDN stores the certificate public key, and the server (source site) stores the certificate private key. In the process of TLS authentication and key negotiation between CDN and browser, the information in the negotiation process is forwarded to the source website in the form of HTTP or HTTPS through secure channels. In this scheme, CDN does not cache, but only uses its own accelerated network to quickly send users’ requests to the server (source station) and reduce the public network delay. Therefore, this scheme is suitable for source site acceleration which has higher security requirements and is unwilling to share the certificate private key with THE CDN. For HTTPS domain name to be CNAME bound to another HTTPS domain name, in this case, you need two certificates, because each certificate is bound to its own domain name, even though they’re both on the same server, You cannot use the same certificate. The CA certificate is deployed on one server but the service system is deployed on another server. This situation is difficult. In this case, you need to use Nginx reverse proxy, back to the specific server.

Symmetric encryption algorithm can encrypt sensitive information through DES or AES during communication, and then decrypt it directly on the client and server. However, encoding the key in code is a security risk because the key can be leaked. Therefore, it is more secure to store the key in the database, and deliver the key through the interface of the server. When using the key, the client obtains the key and loads it into the memory. In addition, asymmetric encryption algorithms are used to ensure the safe exchange of the key during communication. In fact, the communication flow can learn from the FLOW of THE HTTPS protocol and combine the advantages of symmetric and asymmetric encryption algorithms. Symmetric encryption algorithm is used to encrypt communication content quickly, which makes up for the slow processing speed of asymmetric encryption algorithm and ensures the confidentiality of communication content. At the same time, the asymmetric encryption algorithm is used to encrypt the keys of the symmetric encryption algorithm to ensure the secure exchange of the keys of the symmetric encryption algorithm. Here, introduce a real case of file encryption and decryption. To prevent platform resources from being captured by a third party, the platform resources must be encrypted and can only be used by platform clients. To better understand the flow of communication, let’s look at the steps of encrypted communication.

In the first step, the client SDK uses the RSA encryption algorithm to generate a pair of public and private keys, or encryption keys and decryption keys. Second, the client SDK requests the AES key from the server, because the key is stored in the server’s database, and the server interface delivers the key. The request parameters include the resource ID and the public key of the RSA encryption algorithm. Third, the server generates an AES key using the resource ID in the client SDK request parameter and saves it in the database. Fourth, the server encrypts the AES key using the RSA encryption algorithm public key in the client SDK request parameter. Fifth, the server sends the AES key encrypted by the SDK to the client. Step 6: The client SDK decrypts the RSA encryption algorithm’s private key to obtain the real AES key. Seventh, the client SDK encrypts the resource file using the real AES key. After understanding the communication flow of resource file encryption, let’s observe the communication steps of decryption.

Similar to the communication flow of resource file encryption, the client SDK uses RSA encryption algorithm to generate a pair of public and private keys. The client SDK requests the AES key from the server, and the server queries the AES key using the resource ID in the request parameter of the client SDK. The server uses the RSA encryption algorithm public key in the client SDK request parameter to encrypt the AES key, and the server sends the ENCRYPTED AES key to the client SDK. The client SDK decrypts the RSA encryption algorithm private key to obtain the real AES key. Finally, The client SDK decrypts the resource files using real AES keys. HTTPS degrade attack Scenario Analysis and Solution Is HTTPS secure HTTP is not encrypted and communication is transmitted in plaintext without any security processing. Therefore, HTTPS is used to address risks such as eavesdropping, tampering, and impersonation. HTTPS encrypts communication content, preventing third-party eavesdropping. HTTPS can be used for identity authentication. Once the communication content is tampered, the communication parties will immediately discover it. In addition, HTTPS ensures the integrity of communication content and prevents communication content from being impersonated or tampered with. So, can HTTPS be used to ensure the secure transmission of communication content? In theory, this is true, but in reality, this is not the case, because there are flaws in the design and implementation of SSL/TLS that allow attackers to attack older versions of SSL/TLS as well. This includes SSL 3.0. What is HTTPS degrade Attack? If the browser fails to connect to HTTPS due to compatibility problems, the browser tries to use an older protocol version. As a result, the encryption protocol is degraded from a more secure one, such as TLS 1.2, to SSL 3.0. Therefore, in AN HTTPS degrade attack, an attacker exploits vulnerabilities in older VERSIONS of SSL/TLS protocols, including SSL 3.0, and then exploits certain encrypted plaintext communications in secure connections that can be degraded to SSL 3.0. Note that if the server supports SSL protocol 3.0, at the same time, the attacker is able to control the browser as a middleman by holes version of the HTTPS requests, at this point, although the attacker hacking into the encrypted communication content, but encryption protocol loophole, can undertake downgrade attacks, decrypt the encrypted content of communication can get valuable information, For example, users’ private data. Currently, the only solution to HTTPS degradation attacks is to disable SSL 3.0 and prevent TLS 1.2, TLS 1.1, and TLS 1.0 from being degraded to SSL 3.0. There are many policies to disable SSL 3.0. This section describes how Nginx prevents TLS 1.2, TLS 1.1, and TLS 1.0 from being degraded to a version later than SSL 3.0 to prevent HTTPS degradation attacks. The original configuration of Nginx is shown below. At this point, the implicit default in Nginx is SSLv3 TLSv1 TLSv1.1 TLSv1.2 if there is no additional configuration for the original Nginx configuration. Ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; The configuration of Nginx to disable SSL 3.0 and prevent TLS 1.2, TLS 1.1, and TLS 1.0 from being degraded to SSL 3.0 is very simple, simply masking the SSLv3 parameter, as shown below. Ssl_protocols TLSv1 TLSv1.1 TLSv1.2; In summary, can HTTPS ensure the secure transmission of communication content? The answer is not necessarily, because there are vulnerabilities in the design and implementation of SSL/TLS protocols, which allow attackers to attack some older versions of SSL/TLS protocols, including SSL 3.0, which may be degraded by HTTPS attacks. Therefore, SSL 3.0 is insecure. To prevent HTTPS degradation attacks, you need to disable SSL 3.0 and ensure that TLS 1.2, TLS 1.1, and TLS 1.0 are degraded to SSL 3.0.

Source: author: Liang Guizhao links: https://juejin.cn/post/6844903485327015950 the nuggets copyright owned by the author. Commercial reprint please contact the author for authorization, non-commercial reprint please indicate the source.