All-station HTTPS, not that simple.

"Full station HTTPS" has become the current hot topic, many websites are gearing up to implement the whole station HTTPS. Coincidentally, we (Hujiang) are also pursuing this plan.

At first everybody thought is very simple, the certificate purchase, the match is good, the corresponding path changes, has no problem. It is true that the HTTPs transformation of a single stand-alone site is easy. Once to the "whole station", only to find things far more complicated than imagined, the whole station means all the resources to face all clients, the factors involved are unusually many, the network does not have much information, only their own groping. I will briefly talk about some of the problems encountered, provide some experience for everyone to reference.

　　HSTS

If a Web site provides both an HTTP service and an HTTPS service (which is usually the case during a transition period), how do you direct users to HTTPS sites? This is the role of HSTS (HTTP Strict Transport Security). With the settings on the WEB server, when an HTTP access request is received, the returned header has a strict-transport-security field that informs the browser that it must be accessed using HTTPs.

However, HSTS is not able to avoid the hijacking that was encountered during the first jump. To solve this problem completely, you can apply to join the Preload list (pre-load lists).

Preload list is a "HTTPs site list" maintained by Google Chrome, which is used by Chrome, Firefox, Safari, Edge, IE 11. Once the browser discovers the site to be accessed on the preload List, an HTTPs link is initiated by default. This avoids the risk of HSTS's first jump being hijacked.

　　SSL Offload

In the usual scheme, the encrypted transmission of HTTPs is limited to the public network phase of the client, and the traffic in the intranet still uses the non-encrypted HTTP transmission. This "convert encrypted traffic to non-encrypted traffic" process, is often said SSL/TLS offload (offloading, hereinafter referred to as "SSL offload").

Some companies will use F5 to do load balancing, F5 to deal with pure L4 and L7 traffic is not a problem, but the performance of SSL offload is often reduced sharply, F5 can provide a special accelerator card to solve this problem, but the price is not cheap. Therefore, a special link is required for SSL offload, common Nginx and HAProxy can perform this task.

After the 2010 Intel-produced Westmere series processors, the CPU supports the AES-NI (Advanced Encryption Standard NEW instructions) instruction set, which greatly increases the speed at which the software is SSL-decrypted (through The usual data is about 5 times times that). However, the mere adoption of CPUs does not directly benefit from this, and the corresponding OpenSSL is required to provide support. If you want to know if your OpenSSL is using aes-ni acceleration, you can use the command line of OpenSSL to debug, plus the-EVP parameter, whether the test speed has changed significantly.

# without EVP API

OpenSSL speed AES-256-CBC

Doing aes-256 CBC for 3s over size blocks:14388425 aes-256 CBC ' s in 3.00s

# with EVP API

OpenSSL SPEED-EVP AES256

Doing AES-256-CBC for 3s on + size blocks:71299827 AES-256-CBC ' s in 3.00s

　　Client certificate

The HTTP service is well-validated. In general, the results are the same regardless of whether the client is a browser, a tool, or a program code. So as long as a client-side verification, the basic can be considered that the service is not a problem. This is not the case for HTTPs sites.

Unlike HTTP, the connection of HTTPs is established by the need for certificate authentication, must start from the root certificate to form a complete chain of trust, the connection can be established successfully. However, browsers, common tools, program libraries, and their trusted root certificates are managed independently of each other. For example, unlike a browser, a C # Trusted root certificate is in the local machine store or the current user store, and the Java trusted root certificate is in the Cacerts directory in the JDK installation directory.

Because the browser's certificate in use and can be continuously updated, the user is often not aware of, if "take for granted" that browser verification through the good, it is likely to be problematic. For example, many domestic websites use wosign issued certificates, but the old version of the JDK and step-trust wosign root certificate, browser Browse the site is not a problem, the program will error, unless manually import the certificate. Because of wosign misconduct, a few days ago, Firefox, Chrome, Safari and other mainstream browser to cancel its trust, it means that the Wosign certificate has a security risk, so already built-in Wosign root certificate program should also do the corresponding settings.

　　Server-side certificates

Or the above phenomenon: use the browser to verify that there is no problem with the HTTPs site, access to the program has a problem. Why is this?

I have seen the certificate configuration error on the server, only the final certificate, and the lack of intermediate certificates. In general, the final certificate contains intermediate certificate-related information, so if the lack of intermediate certificates, the browser in order to establish a certificate chain, a time-consuming operation to obtain intermediate certificates, and all this occurs before the HTTPs connection is really established. To make matters worse, many browsers will try to circumvent the problem in order to "perform better". So the lack of intermediate certificate has been there, has not been found, and the speed of the program calls always go up, and even a certain chance of error (I have encountered this strange problem).

If the certificate chain is fully configured, also pay attention to the size of the certificate chain. Some Web sites have full certificates that are unusually large, reaching several KB or even dozens of KB, meaning that so much data must be transferred before a connection can be established. If you do a simple PC web browsing, perhaps there will be no problem. But for mobile and program calls, this is a disaster. The best way to do this is to use OpenSSL with tools such as WireShark to test it yourself. If you are familiar with TCP-related knowledge, you can often get better optimization schemes.

OCSP and CRLs are also not negligible. These two techniques are used to guarantee the validity of the revocation certificate (which invalidates the certificate). If you look closely, you will find that the certificate specifies the URL of the corresponding OCSP or CRL to check if the certificate is invalid. In principle, an OCSP or CRL check should be performed each time an HTTPs connection is established. The return result is usually around 1k, which should also be considered if the request is very frequent.

　　Tn.

Everyone is familiar with the concept of "virtual host", which can make multiple domain names correspond to the same IP, and let the same server serve multiple sites. In the HTTP era, you can use host in the header to specify the domain name you need to access, everything looks perfect.

But in the HTTPS era, there is no such thing, the traditional HTTPS service is difficult to allow multiple domain names to the same IP. Before you can communicate to HTTP, you must establish a validation certificate to establish a connection. If an IP is bound to multiple domain names, this stage of the server simply can not know the request is the corresponding domain name, will undoubtedly cause great inconvenience.

In order to solve this problem, SNI (Server Name identification) was born. This technology is complex, you can simply understand it as "the establishment of the SSL/TLS communication host Header", which solves the problem of an IP can only be a single certificate.

The birth history of SNI is not long, however, and there are strange problems with the support of many clients. For example, JDK7 supports SNI, but JDK8 's support has bugs. And this kind of support often needs to call native APIs to be implemented, and class libraries such as Resteasy are not supported. If there is a problem with support for SNI, the connection may not be established even if it is configured correctly because the server does not recognize the certificate required for this request.

　　Cdn

CDN is already a popular technology in the industry, for a slightly larger site, no CDN is almost unthinkable. The CDN scheme in the HTTP era is quite mature, not the case with HTTPs.

To use the CDN service with HTTPs, decide whether to give the certificate to the CDN provider. Based on the current level of business reputation in China, the risk of handing over certificates to CDN providers is not considered. Malicious speculation, the people with ulterior motives once the certificate has been obtained, it is convenient to initiate a man-in-the-middle attack through the DNS hijacking, without being completely perceived.

In addition, in the HTTP era, we all like to spread resources across many different domain names, because the cost of establishing a connection is low, and the number of concurrent connections to the same domain name is limited. In an HTTPs environment, the cost of establishing a connection is much higher each time, and frequent downloads and verification of certificates have a significant impact on mobile devices and mobile networks (especially in cases where certificates are large). If the domain name is very fragmented, the impact is even more pronounced. So in the HTTPs era, the domain name contraction is a better way to focus.

　　Content and other

Because HTTP resources cannot be referenced in HTTPS content, you should ensure that the links to the resource files in the Web page are https. Many of the legacy systems are probably not paying attention to these things, and the resources are in the form of absolute addresses, which can be a lot of work to change. If you want to modify, it is best to one step, directly to the "protocol relative URL".

Absolute address Url:http://www.a.com/b.css

Protocol relative URL://WWW.A.COM/B.CSS

This allows the browser to automatically generate the absolute address of the resource based on the current protocol, whether HTTP or HTTPs, and can switch freely.

If resources are owned, switching HTTPs is relatively easy. Switching to HTTPs is cumbersome if there are external, especially UGC-resourced resources. In the case of hyperlinks, a dedicated jump service is usually used, which is the following:

Https://link.my.com/target=www.you.com

If it is a picture of such resources, you can set up a special program to crawl it to store on their own server, and then replace the address. However, it is very likely that you will have to bear the traffic pressure, and also bear the risk of malicious program attack.

If it is a video, game and other rich text, interactive complex resources, if the source station does not provide HTTPs services, most can only reluctantly, abandon the form of embedded presentation.

Finally, add two more experience:

1. If you really decide on HTTPs, it is best to have a person to play OpenSSL, or many problems will make you feel the mind, OpenSSL is a good debugging tool, very convenient location problems.

2. HTTPS can solve the problem of carrier content hijacking, if it is a DNS hijacking, should not hold the "I and Ru died" attitude on the HTTPS, need to carefully consider, I know a lot of websites are HTTP and HTTPs can switch at any time, into the offensive, back can be kept.

This article permanently updates the link address : http://www.linuxidc.com/Linux/2016-11/137212.htm

All-station HTTPS, not that simple.