How to make https certificate and HTTPS?

1. Why must we upgrade to HTTPS?

The HTTP protocol is widely used and has made great contributions to the development of the Internet. The Internet has evolved from an initial media and content platform to a platform that connects people and services and completes a closed-loop transaction ecosystem. Especially in the era of "Internet +", the data interacted on the Internet has become more private and important, and HTTP has gradually exposed its shortcomings:

The HTTP protocol communication process is in plain text, while the TCP/IP protocol essentially works based on a store-and-forward mechanism. In the data link from the server port to the browser, various intermediate links (such as proxies, gateways, routers, WIFI hotspots, malicious drivers, malicious browser plug-ins, etc.) can easily monitor and modify the datagrams passing through, leading to information leakage and malicious tampering.

The HTTP protocol does not have an authentication mechanism for users and websites. The URL entered by the user on the browser may be hijacked by the DNS, causing the user's browser to be directed to a fake website. The user communicates with the fake server and important information such as account number and password may be obtained by fraud.

The HTTP communication process is maliciously hijacked and tampered with, but ordinary users cannot tell the difference and will blame all problems on the website or APP developers, which will have an adverse impact on the normal operation and brand of the website and APP.

Hackers insert malicious code or viruses during HTTP communication to conduct two-way intrusion and attack.

Take a certain SaaS product as an example. In 2015, the PC side of the merchant of this product encountered three page content hijacking incidents. During user use, maliciously inserted advertisements and JS codes appeared in the page, affecting the normal function of the page, causing the merchant's backend system to be unable to be used normally, affecting the merchant's business process, and leading to user complaints and refunds.

According to statistics, in the third quarter of 2015, the hijacking rate of the user-side APP of this product was 2-3%.

How to deal with HTTP hijacking?
More and more Internet applications are choosing full-site HTTPS solutions. From a global perspective, full-site HTTPS is a must.

Internet finance, e-commerce, and Internet payment industries have long used full-site HTTPS to improve application security.

In March 2015, Baidu announced that it had entered the era of full-site HTTPS, making all access to Baidu searches encrypted. Baidu became the first Internet company in China to adopt HTTPS for its entire website.

In May 2015, Baidu search engine fully supported the inclusion of HTTPS sites and gave them priority in ranking.

In July 2015, Alibaba's Taobao and Tmall websites all adopted HTTPS, becoming the first e-commerce platform in China to adopt HTTPS for the entire website.

In June 2016, Apple announced that by January 1, 2017, all apps in the App Store must enable the App Transport Security security feature.

App Transport Security (ATS) is a privacy protection feature introduced by Apple in iOS 9. It blocks the loading of plaintext HTTP resources and requires connections to go through the more secure HTTPS.

As a cloud platform that is the foundation of Internet applications, it is both important and necessary to provide tenants with convenient and reliable HTTPS functions in cloud products to cope with harsh Internet environments.

2. How to implement HTTPS for the entire Baidu site?

There are already many articles online introducing the working mechanism of the HTTPS protocol, so I will not go into details here. Here we take Baidu's full-site HTTPS as an example to introduce the problems you will encounter when upgrading an Internet application to full-site HTTPS, as well as some solutions.

Challenge 1: Dealing with compatibility Since Netscape released the SSL protocol in 1995, the HTTP protocol has been popularized from 1.0 to HTTP1.1, and HTTP2.0 is also becoming popular.

The secure transport layer protocol has also gone through five versions: SSL v2.0, SSL v3.0, TLS 1.0, TLS 1.1, and TLS 1.2. TLS1.3 will be launched soon, although security vulnerabilities have been found in SSL v2.0, SSL v3.0 and TLS 1.0, and they are gradually being discontinued in new operating systems and new browsers.

However, due to national conditions, there are still a small number (about 2%) of old browsers in the Chinese market that use these flawed encryption transmission protocols.

Solution to Challenge 1:

For small Internet applications, since there are relatively few users, giving up support for old versions of systems and browsers and requiring users to upgrade to recommended versions will not be a big problem. However, for large websites and applications with nearly 10 billion PVs per day, obviously giving up support for these old browsers will result in huge traffic losses.

Therefore, when large-scale Internet applications are upgraded to HTTPS, compatibility with lower-version systems must be considered. For example, service downgrade: access that does not support higher versions of TLS is downgraded to use lower versions of the HTTPS protocol; both SHA-1 and SHA-256 are supported to improve algorithm compatibility; for users who really cannot use HTTPS, their access is redirected with a 302 redirect and normal HTTP access is restored.

Challenge 2: Dealing with processing delays and decreased concurrency

Ignoring the DNS resolution process, under the HTTP protocol, as long as TCP interactions are completed three times, you can start sending requests and returning results. Because HTTPS adds complex steps such as certificate verification and key negotiation, the number of interactions will increase by 3-7 times depending on the cache hit status.

Without optimization, it will cause a delay of 250-500ms, and for poor quality pages it may worsen by 500-1200ms.

At the same time, various symmetric, asymmetric and hash algorithms consume computing time and add tens of milliseconds of delay. Since asymmetric encryption and decryption consumes a lot of computing resources, it will also lead to a decrease in server concurrency performance.

Assume that when using HTTP, the CPS of a website can reach more than 20,000. After using HTTPS, the CPS will drop to about 2,000-3,000.

Solution to Challenge 2:

In order to deal with the surge in latency and computing power without significantly affecting the user experience, large websites will optimize communication protocols, encryption algorithms, backend architecture, traffic scheduling, front-end pages, and operation and maintenance management. The steps are as follows.

1. At the protocol layer, try to use TCP fast open (TFO RFC7413), HSTS, Session Cache, Session Ticket, Ocsp stapling, False start, SPDY/HTTP2 and other technologies for compatible clients to reduce the number of handshakes, reduce the number of jumps, and increase the connection reuse ratio.

2. Make a pre-connection at the application layer and complete the handshake process in advance before the web page or client user initiates an access request to reduce latency.

3. In terms of algorithms, ECC is preferred for performance optimization. The ECC key length used here is shorter than the RSA and DH key lengths.

4. In the backend architecture, you can use SSL hardware acceleration cluster to perform SSL offloading.

The following figure is a performance comparison of the server processing HTTPS access in an experimental environment, using SSL hardware acceleration and not using hardware acceleration. It can be seen that the use of hardware acceleration improves the server's concurrency several times, while reducing the server CPU load and greatly reducing the response time.

5. SSL hardware acceleration effect experiment

Challenge 3: Dealing with HTTPS attacks

1. Prevent protocol downgrade attacks

There are generally two types of downgrade attacks: cipher suite rollback and protocol downgrade attack (version roll back).

The principle of a downgrade attack is that the attacker forges or modifies the client hello message, causing the client and server to communicate using a weaker encryption suite or protocol.

Solution: To deal with downgrade attacks, the SCSV function is now implemented between the server and the browser (refer to https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00 for the principle).

2. Prevent renegotiation attacks

There are two types of TLS renegotiation: cipher suite renegotiation and protocol renegotiation. There are two hidden dangers in renegotiation:

*Use a weak security algorithm after renegotiation. The consequence of this is that the transmitted content can be easily leaked.

*Full handshake requests are continuously initiated during the renegotiation process, triggering the server to perform high-intensity calculations and causing service rejection.

Solution: For renegotiation, the most direct protection measure is to prohibit the client from actively renegotiation. Of course, for the needs of special scenarios, the server should be allowed to actively initiate renegotiation.

Challenge 4: All resources involved in the front-end page must support HTTPS

The purpose of HTTPS is to ensure the security of the transmission process. If only the main domain name is on HTTPS, but the resources loaded by the main domain name, such as js, css, and pictures, are not on HTTPS, the browser will alert the user and prevent the user from continuing to access the page.

If the user is forced to continue accessing, the purpose of ensuring the security of the website transmission process is not achieved, because your js, css, and images are still likely to be hijacked. If these contents are tampered with/sniffed, then the meaning of HTTPS is lost.

Solution to Challenge 4:

In fact, the deployment method and difficulty of HTTPS vary greatly for different sites.

For a large site, enabling the webserver to support HTTPS and optimizing the HTTPS protocol features of the webserver may only account for 20%-40% of the migration work. Making the CDN system, front-end resources, templates, and service addresses support HTTPS is a more time-consuming and labor-intensive task.

6. Key points of HTTPS transformation of front-end pages

3. How can small and medium-sized websites enjoy Baidu’s benefits for free?

After seeing Baidu’s practice, do you feel that implementing HTTPS for the entire site is a daunting task and make you feel bad?

In the past, if you wanted to transform a web application to HTTPS, you had to go through tedious steps such as generating public and private keys, creating a certificate application, applying for a certificate, enabling HTTPS functions on load balancing, servers, and CDNs, deploying certificates and private keys, optimizing performance, and so on.

So, is there a more elegant way that is cheaper and quicker?

You can try Baidu Open Cloud, and it is said that:

Free application and free reuse of Baidu Experience

No need to modify the source site, just one step

Dynamically added, effective immediately

Tenant certificate private key transmission and storage are all encrypted

Compatible with HTTP request processing, no worries

Flexible publishing, SSL protocol version back to the source can be switched at will