Difficulties in accessing WeChat Mini Programs
The Lunar New Year is approaching, and WeChat Mini Programs are also released as scheduled. Developers will encounter the following problems when accessing WeChat Mini Programs:
The mini program requires that communication with the server must be completed through HTTPS. If the developer chooses to build the HTTPS service by himself, he needs to apply for and deploy his own SSL certificate to complete the https service establishment, which is inefficient and the process is lengthy; and the SSL of HTTPS is parsed and needs to be parsed on the server. The CPU has significant overhead.
Not only mini programs, Apple iOS platform and Google Android also gradually mandated developers to use HTTPS access in 2017. HTTPS seems to be an unavoidable threshold, causing headaches for many developers.
In response to the above problems, Tencent Cloud's load balancing service (cloud load balance) hopes to provide one-click SSL certificate application services by optimizing the performance of HTTPS, lowering the application threshold and usage cost of HTTPS, allowing Developers can quickly access services such as WeChat mini programs. First, let’s take a look at HTTP vs. HTTPS to unravel your mysteries one by one.
2. Why should you access HTTPS - the security risks of HTTP
HTTP protocol is a very simple and efficient protocol. Most mainstream applications on the Internet use HTTP by default. Due to limitations in performance and usage environment in the 1990s, the HTTP protocol itself is not a protocol designed for security. There is neither identity authentication nor consistency testing. The most troublesome thing is that all HTTP content is transmitted in clear text. .
On the other hand, the development of the Internet is also changing with each passing day, and various HTTP applications continue to penetrate into all aspects of people's lives. Whether it is social networking, shopping, finance, games, or search, these HTTP services can bring people great convenience and improve the quality and efficiency of life.
Obviously, HTTP is closely related to people’s lives and economic interests. Unfortunately, it is not secure. This means that there must be huge safety risks hidden here. These hidden dangers are concentrated in the following two aspects:
1. Privacy leakage
Since HTTP itself is a clear text transmission, the transmission content between the user and the server can be viewed by the middleman. In other words, information such as your online searches, shopping, websites visited, pages clicked, etc. can all be obtained by "middlemen". Since most Chinese people do not pay much attention to the protection of privacy, the risks here are relatively hidden, and the consequences of harm are not easy to quantitatively assess. Some of the more serious known privacy leaks include:
QQ login status was stolen by criminals, and then logged in in a different place to conduct advertising and fraud.
The user’s mobile phone number and identity information were leaked.
User’s online behavior is leaked. For example, if you search for a hospital, someone will soon call to promote it (non-effective advertising).
2. Page hijacking
The risk of privacy leakage is relatively hidden and users are basically unaware of it. But the impact of another type of hijacking is very obvious and direct - page hijacking, that is, directly tampering with the user's browsing page. There are many page hijacks that are very simple and crude, directly inserting third-party advertisements or traffic prompt information from operators.
But there are also some hijackings that are more subtle, such as the following JD page hijacking: The picture above is a page using HTTP, and there is a page indicated by the top arrow. The shopping recommendations are very realistic, just like the official tools of JD.com or browsers.
#But if you switch to HTTPS access, there is no such tool page, and it is obviously hijacked.
3. Hijacking paths and classification
How does hijacking occur? Technically speaking, it is relatively simple. Just monitor and tamper with the content wherever it passes. However, in order to understand the entire hijacking industry chain, we need to go deep into the black industry, which is more difficult. One thing that is certain is that most hijackings occur at intermediate network nodes, also called "man in the middle" (MITM). As shown in the figure below:
Since information transmission needs to go through the above-mentioned "middleman nodes", they also have the permission to read and write information. If the information is not encrypted, there is no verification. If you want to check the privacy and tamper with the page, it is very easy for the "middleman".
What are the main categories of hijacking? According to the hijacking path, there are mainly three categories as shown in the figure below:
DNS hijacking, client hijacking and link hijacking. According to our incomplete statistics, most hijacks (90%) encountered by businesses are link hijacks.
3. HTTPS is a nuclear weapon to solve link hijacking
Why can HTTPS solve link hijacking well? Mainly three weapons:
1. Identity authentication - anti-counterfeiting, anti-repudiation
Every time a new HTTPS connection is established, the identity needs to be authenticated to ensure that the user is accessing Correct purpose website.
2. Content encryption—anti-eavesdropping
Content encryption means that all end-to-end communication content is cipher text, and the middleman cannot directly view the plain text. HTTPS all The application layer content is encrypted and decrypted through symmetric encryption.
3. Consistency verification - anti-tampering
Prevents intermediaries from tampering with message content and ensures data through MAC codes of data and shared keys consistency.
4. The Pain of the Popularization of HTTPS
In fact, HTTPS was born in 1995 and is a very old and mature protocol. At the same time, it can effectively prevent content hijacking and protect user privacy. But why until today, most websites still do not support HTTPS and only use HTTP?
The main reason affecting the popularity of HTTPS can be summarized in two words: " "Slow" and "expensive".
1. Slow
Without any optimization, HTTPS will seriously reduce the user's access speed. The main factors include:
Network time-consuming. Due to the provisions of the protocol, network transmission must be carried out. For example, SSL full handshake, 302 jump, etc. Worst case scenario this could add 7 RTTs.
Calculation time. Both the client and the server need to perform symmetric encryption and decryption, protocol analysis, private key calculation, certificate verification and other calculations, which adds a lot of calculation time.
2. Expensive
HTTPS is expensive, mainly reflected in the following three aspects:
Server cost. The private key calculation of HTTPS will cause a sharp drop in server performance, which is even less than one-tenth of the HTTP protocol. In other words, if the performance of HTTP is 10,000 cps, the performance of HTTPS may be only a few hundred cps, which will increase several times or even Dozens of times the server cost.
Certificate cost. Depending on the number and type of certificates, certificate costs may range from hundreds to millions per year.
Development and operation and maintenance costs. The HTTPS protocol is relatively complex, and security bugs often occur in the open source implementation of openssl. A series of issues including protocol configuration, certificate updates, expiration monitoring, client compatibility, etc. require technical personnel with professional backgrounds to follow up and deal with them.
5. Tencent Cloud Load Balancer HTTPS Performance Optimization
Tencent Cloud Load Balancer has deeply optimized the pain points in the process of HTTPS promotion and application. . Next, we introduce these optimization plans in detail:
1. Optimization of access speed
As mentioned earlier, HTTPS is very slow. We have also optimized the access speed mainly from two levels: Protocol stack and front-end and back-end resources.
Full-link protocol stack optimization
HTTPS can be considered as HTTP over SSL, and HTTPS uses the TCP protocol for transmission, so the optimization of the entire protocol stack involves three levels:
TCP optimization. Including congestion window adjustment, tcp fast open, reuseport support, support for the latest BBR congestion control algorithm, etc.
SSL protocol optimization. Distributed session cache, session ticket, False start, ocsp stapling file, dynamic record size, etc.
The most important goal of SSL protocol optimization is to increase the proportion of simplified handshakes. Tencent Cloud improves the simplified handshake ratio of SSL by implementing a global session cache and a global session ticket, saving user access time and computing resources.
Application layer protocol optimization. Also supports SPDY, HTTP2, HSTS, etc.
The biggest advantage of HTTP2 compared to HTTP1.X is multiplexing, which can send multiple HTTP requests in parallel through a TCP connection. Compared with the serial sending of HTTP1.X, the performance is undoubtedly A lot of improvement.
Since HTTP2 is inherited and developed from SPDY, some older clients only support SPDY and not HTTP2. Most new clients only support HTTP2 and do not support SPDY. In order to be compatible with the performance of both old and new clients, Tencent Cloud supports both SPDY and HTTP2 to maximize the performance of old and new clients.
Front-end and back-end optimization
The biggest feature and advantage of HTTP2 and SPDY is multiplexing, which can send multiple requests in parallel through one connection. Although this feature is very powerful, if traditional HTTP optimization strategies are still used, the effect of multiplexing will be very limited. For example, domain name sharding, pipeline, etc. will affect the multiplexing effect. So we conducted many data experiments and adjusted some front-end resources including back-end access strategies:
Domain name retrieval. Through page resource and performance analysis, confirm the domain name retrieval plan, such as moving no more than 3 pages.
Pre-built connections. STGW provides pre-connection pages. By analyzing user behavior on hot pages, connections are established in advance to reduce the impact of protocol overhead on user experience.
Complete HTTPS offloading through Tencent Cloud’s global CDN and IDC nodes.
2. Computing performance optimization
For the computing performance of HTTPS, Tencent Cloud has mainly optimized it from three levels, including:
Minimize the complete handshake occurs, improving the simplified handshake ratio. For example, the global sessioncache and session ticket mentioned earlier.
For the inevitable complete handshake, Tencent Cloud has implemented RSA asynchronous proxy computing. Through the transformation of the protocol stack and the use of SSL hardware accelerator cards, the computing power and attack defense capabilities of HTTPS have been greatly improved.
The symmetric encryption calculation process has also been optimized for use in scenarios.
Let’s introduce it in detail below:
RSA asynchronous proxy computing
Tencent Cloud targets the most serious link in HTTPS performance consumption—the asymmetric key exchange algorithm. Focused optimization. The optimization ideas mainly include the following three parts:
Algorithm separation. This means stripping out the algorithms that consume the most CPU resources and preventing them from consuming local CPU resources.
Agent calculation. Use an idle CPU machine or a dedicated SSL hardware acceleration card to complete RSA calculations.
Asynchronous execution. When traditional openssl performs RSA, upper-layer applications, such as NGINX, need to wait synchronously. This step is also very influential and must be modified asynchronously so that when the cluster is accelerated for RSA calculations, the access server can also receive requests from other users to improve throughput.
Through the in-depth transformation of the openssl handshake protocol stack and the RSA computing performance of the SSL hardware accelerator card, the SSL computing power of Tencent Cloud CLB has been increased by 350%. The single-machine ECDHE_RSA processing performance reaches 65000 cps.
Automatic optimal selection of symmetric encryption algorithm
Tencent Cloud matches the optimal symmetric encryption algorithm according to the application scenario:
For streaming media content such as videos, aes- is preferred gcm.
For mobile terminals that do not support aes-ni hardware acceleration instructions, use chacha20-poly1305.
For antique-level clients such as IE6, use the RC4 algorithm.
#3. Parallel unloading of protocols
Tencent Cloud CLB supports access and offloading of all current mainstream HTTP protocols. Including:
http1.0/http1.1
http2 and its predecessor spdy3.1
https, including ssl3.0, tlsv1.0, tlsv1.1, tlsv1. 2
websocket and secure websocket.
tcp, udp transparent forwarding.
CLB can uniformly convert the above seven-layer protocols into HTTP1.1 and transparently transmit them to the business. The benefits to the business are also very obvious: HTTPS and HTTP2 can be used with zero development cost, which greatly reduces the pressure of adapting to various protocols and clients.
4. Security
The fields and scenarios involved in security are very large. Although HTTPS can completely solve link hijacking, it is powerless against the following two types of problems:
CC attacks, especially HTTPS computing attacks, the performance of HTTPS will be A sharp decrease introduces greater security risks.
Business security, including SQL injection, XSS cross-site, website malware, etc.
The above two categories are extremely risky security issues that often plague businesses.
In response to the above problems, Tencent Cloud has also designed and implemented a security system to prevent CC and WAF for HTTPS, which can effectively defend against such security risks.
The importance of Keyless (no key loading) private key
Friends who are slightly familiar with certificates know that SSL keys and certificates are both For use, a certificate must uniquely correspond to a private key. The most important piece of data in the entire HTTPS is the SSL private key. If the private key is leaked, the entire handshake process can be hijacked, the signature can be forged, and the symmetric key can be cracked. There is nothing secure about HTTPS as a whole.
Traditional private key usage solutions and risks
The traditional private key solution is to bind the private key to the application. For example, if you want to use HTTPS with the well-known nginx and apache, you must deploy the relevant certificates and private keys on the access machine where nginx is deployed.
This solution will have the following security issues: The private key is deployed in the cloud or CDN. What if it is leaked?
No secret key method
Although Tencent Cloud's intranet is very secure, out of responsibility for the security of its customers, it completely dispels users' concerns about private key leaks and ensures that users are safe and secure about their private keys. For absolute control, Tencent Cloud provides a private key-free loading solution. The core of this solution is that "there is no need to store private keys in Tencent Cloud, allowing users to use their own servers to store private keys and complete HTTPS access." Tencent Cloud has no access to private keys, and customers can even store private keys on their own servers at home.
Its access process is as follows:
The user initiates an HTTPS handshake request.
When it comes to private key calculation, Tencent Cloud CLB will forward the private key calculation request to the user's own keyless server through an encrypted custom protocol.
The keyless service calls the user’s private key to complete the calculation.
The keyless service returns the calculation results to Tencent Cloud CLB.
CLB continues processing of HTTPS requests.
During the entire process, Tencent Cloud has no access to the HTTPS private key. It should be noted that the keyless server is a server program provided by Tencent Cloud. The code is open source, users can deploy it independently, and users can control the server behavior. Clear as day.
6. Zero threshold, HTTPS quick access to WeChat applet
Tencent Cloud CLB load balancer realizes through in-depth optimization of the protocol stack and server A huge improvement in HTTPS performance. At the same time, we have also greatly reduced the cost of certificates by cooperating with internationally renowned certificate agencies. Tencent Cloud CLB can bring very significant benefits to WeChat mini program access in the following aspects:
Provides one-click SSL certificate application, CLB load balancing service serves as an HTTPS proxy, reducing development burden. Allow developers to focus on the development of small program business.
Using HTTPS will not reduce the client-side access speed. HTTP and HTTPS access delays are almost the same.
SSL encryption and decryption performance of a single server in the cluster, up to 6.5Wcps full handshake. Compared with high-performance CPUs, it is improved by at least 3.5 times, saving server costs, greatly improving service capabilities when business operations and traffic surge, and enhancing computational attack defense capabilities.
Supports multiple protocol unloading and conversion. Reduce the pressure on the business to adapt to various client protocols. The business backend only needs to support HTTP1.1 to use HTTP2, SPDY, SSL3.0, TLS1.2 and other versions of protocols. Meet the protocol requirements of WeChat mini programs, iOS platforms, etc.
SSL certificate application, monitoring and replacement. We have in-depth cooperation with comodo and symantec, the top international certificate manufacturers, and have a complete service system.
Anti-CC and WAF functions. It can effectively prevent application layer attacks such as slow connections, high-frequency fixed-point attacks, SQL injection, and web page malware.
#The above benefits can help developers lower the trial threshold of HTTPS.
More small program developers need to pay attention to the in-depth analysis of the HTTPS protocol and related articles, please pay attention to the PHP Chinese website!