Run to the full site HTTPS. You have to check the experience.

Run to the full site HTTPS. You have to check the experience.

As the domestic network environment continues to deteriorate, various kinds of tampering and hijacking emerge one after another, and more websites choose full-site HTTPS. Just a few days ago, the free certificate service Let's Encrypt project was also officially open for testing, and HTTPS will soon become a mandatory WEB option. Through the TLS layer and certificate mechanism, HTTPS provides three functions: Content encryption, identity authentication, and data integrity, which can effectively prevent data from being viewed or tampered with, and prevent man-in-the-middle impersonating. This article shares some experience in enabling HTTPS, focusing on how to work with some new security specifications. As for the deployment and optimization of HTTPS, I have written a lot before and I will not repeat this article.

Understand Mixed Content

HTTP resources loaded in HTTPS web pages are called Mixed Content. Different browsers have different processing rules for Mixed Content.

Early Internet Explorer

When early IE finds a hybrid content request, it will pop up "do you only want to view the content of the secure transfer webpage ?」 In such a modal dialog box, once you select "yes", all mixed content resources are not loaded. If you select "no", all resources are loaded.

New IE

Compare the new IE to change the modal dialog box to the prompt bar at the bottom of the page, which does not interfere with the user as before. By default, mixed image content is loaded. Other resources such as JavaScript and CSS are determined based on user selection.

Modern Browser

Modern browsers (Chrome, Firefox, Safari, and Microsoft Edge) basically comply with the W3C Mixed Content specification. The Mixed Content is classified into Optionally-blockable and Blockable:

The Optionally-blockable mixed content contains resources that are less risky and can be tampered with by middlemen. By default, modern browsers load such resources and print warning messages on the console. Such resources include:

• PassImages loaded by tags (including SVG images );
• Pass<video>/<audio>And<source>Video or audio loaded by tags;
• Prefetched resources;

In addition, all mixed content is Blockable, And the browser must disable loading of such resources. Therefore, in modern browsers, HTTP resources such as JavaScript and CSS on HTTPS pages are not loaded and error messages are printed directly on the console.

Mobile browsers

As mentioned above, it is the act of a desktop browser. mobile terminals are complicated. Most mobile browsers currently allow loading all mixed content by default. That is to say, for mobile browsers, HTTP resources in HTTPS, whether in images, JavaScript, or CSS, are loaded by default.

Supplement: The conclusion above is derived from my testing conducted more than half a year ago. In this article, ayanamist commented that the status quo has changed. I did some tests again, and with the upgrade of the operating system, mobile browsers began to follow the mixed content specifications. The latest test shows that for the mixed content of the Blockable class:

• Safari under iOS 9 and Webview under Android 5 are loaded by default;
• Android versions of Chrome, Safari for iOS 9 +, and Webview for Android 5 + are not loaded by default;

Generally, if you select full-site HTTPS, you must avoid mixed content. All page resource requests must follow the HTTPS protocol to ensure that all browsers on all platforms are normal.

Reasonable Use of CSP

CSP is short for Content Security Policy. It has many commands to implement various functions related to page Content Security. Here we only introduce two HTTPS-related commands. For more information, see Content Security Policy Level 2.

Block-all-mixed-content

As mentioned above, modern browsers load Optionally-blockable HTTP resources such as images in HTTPS by default. The hijacking of image resources usually does not cause too many problems, but there are also some risks. For example, many web buttons are implemented using images, and the man-in-the-middle will remove these images and interfere with the user's use.

Through the CSP's block-all-mixed-content command, the page can enter the Strict Mixed Content Checking mode. In this mode, all non-HTTPS resources are not allowed to be loaded. Like all other CSP rules, you can enable this command in either of the following ways:

HTTP Response Header:

1. Content-Security-Policy: block-all-mixed-content

<meta>Tag Method:

1. <metahttp-equiv="Content-Security-Policy"content="block-all-mixed-content">

Upgrade-insecure-requests

During the process of migrating a long-standing large site to HTTPS, the workload is often huge, especially replacing all resources with HTTPS, which is easy to cause omissions. Even if all the Code confirms that there is no problem, it is very likely that some fields read from the database still have HTTP links.

Through the CSP command upgrade-insecure-requests, the browser can help with this conversion. After this policy is enabled, there are two changes:

• All HTTP resources on the page will be replaced with the HTTPS address and then initiate a request;
• All site links on the page will be replaced with the HTTPS address after clicking;

Like all other CSP rules, this command can be enabled in two ways. For the specific format, see the previous section. Note that upgrade-insecure-requests only replaces the Protocol part, so it is only applicable to scenarios where the HTTP/HTTPS domain name and path are exactly the same.

Rational use of HSTS

After the full site HTTPS, If you manually enter the HTTP address of the website, or click the HTTP link of the website from other places, the HTTPS service can be used only when the server jumps to 301/302. The first HTTP request may be hijacked, causing the request to fail to reach the server, thus forming an HTTPS downgrade hijacking.

Basic use of HSTS

This problem can be solved through HSTS (HTTP Strict Transport Security, RFC6797. HSTS is a response header in the following format:

1. Strict-Transport-Security: max-age=expireTime [; includeSubDomains][; preload]

• Max-age, in seconds, is used to tell the browser that the website must be accessed through HTTPS within the specified time. That is, for the HTTP address of the website, the browser must replace it with HTTPS locally before sending the request.
• IncludeSubDomains, an optional parameter. If this parameter is specified, all subdomain names of the website must also be accessed over HTTPS.
• Preload, an optional parameter, which will be used later.

The HSTS response header can only be used for HTTPS response. The website must use the default port 443. The domain name must be used, not the IP address. After HSTS is enabled, once the website certificate is incorrect, you cannot choose to ignore it.

HSTS Preload List

We can see that HSTS can effectively solve HTTPS downgrade attacks. However, for the first HTTP request before the HSTS takes effect, it still cannot be prevented from being hijacked. To solve this problem, browser vendors have proposed the HSTS Preload List scheme: A List is built in. For domain names in the List, even if the user has not accessed the List before, HTTPS protocol is also used; the list can be updated regularly.

Currently, this Preload List is maintained by Google Chrome, and Chrome, Firefox, Safari, IE 11, and Microsoft Edge are all used. If you want to add your domain name to this list, you must first meet the following conditions:

• Have a valid certificate (if SHA-1 certificate is used, the expiration time must be earlier than January 1, 2016 );
• Redirect all HTTP traffic to HTTPS;
• Make sure that HTTPS is enabled for all subdomain names;
• Output HSTS Response Header:
  • Max-age cannot be less than 18 weeks (10886400 seconds );
  • The includeSubdomains parameter must be specified;
  • The preload parameter must be specified;

Even if all the preceding conditions are met, the HSTS Preload List may not be displayed. For more information, see here. Using Chrome'schrome://net-internals/#hstsTool to query whether a website is in the Preload List, or manually add a domain name to the local Preload List.

For HSTS and HSTS Preload List, it is recommended that you do not enable the HTTPS service as long as you cannot ensure that the HTTPS service is always provided. Because once the HSTS takes effect, you want to redirect the website to HTTP, and old users will be infinitely redirected. The only way is to change the domain name.

CDN Security

For a large site, CDN is still used after the whole site is migrated to HTTPS, but you must select a CDN that supports HTTPS. If you use a third-party CDN, you need to consider security issues.

Rational use of SRI

HTTPS can prevent data tampering during transmission. valid certificates can also verify the identity of servers. However, if the CDN server is infiltrated, static files may be tampered with on the server, HTTPS is also powerless.

W3C SRI (Subresource Integrity) Specification can be used to solve this problem. SRI allows the browser to verify whether the resource is tampered with by specifying the digest signature of the resource when the resource is referenced on the page. As long as the page is not tampered with, the SRI policy is reliable.

For more information about SRI, see Subresource Integrity. SRI is not dedicated to HTTPS, but if the home page is hijacked, attackers can easily remove the resource digest and thus lose the browser's SRI verification mechanism.

Understanding Keyless SSL

Another problem is that when using the HTTPS service of a third-party CDN, if you want to use your own domain name, you need to give the corresponding certificate private key to a third party, which is also highly risky.

CloudFlare has developed the Keyless SSL technology for this scenario. Instead of sending the certificate private Key to a third party, you can simply provide a real-time computing Key Server. When CDN uses the private Key, it passes necessary parameters to the Key Server through the encrypted channel, and the Key Server calculates the result and returns it. During the entire process, the private Key is kept in its own Key Server and will not be exposed to a third party.

CloudFlare's mechanism is already open-source. For Details, see this article on their official blog: Keyless SSL: The Nitty Gritty Technical Details.

Well, this article will be written here first. It should be noted that the CSP, HSTS, and SRI policies mentioned in this article are only supported by the latest browsers. For detailed support, you can query them using CanIUse. After switching to HTTPS, there will be a lot of new work to be done in performance optimization. I wrote a lot about this part in my previous blog and I will not repeat it here. I just want to say the most important thing:

Now that HTTPS is used, it is the right way to get HTTP/2.

This article permanently updates the link address: