Some experience sharing on enabling HTTPS

As the domestic network environment continues to deteriorate, various tampering and hijacking emerge in an endless stream, and more and more websites choose to use HTTPS for the entire site. Today, Let's Encrypt is offering free certificate services.   The project is also officially open, and HTTPS will soon become a must for the WEB. HTTPS provides three major functions: content encryption, identity authentication, and data integrity through the TLS layer and certificate mechanism. It can effectively prevent data from being viewed or tampered with, and prevent middlemen from impersonating. This article shares some experiences in enabling HTTPS, focusing on how to use it with some new security specifications. As for the deployment and optimization of HTTPS, I have written a lot before, so I will not repeat it in this article.

Understanding 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 found a Mixed Content request, it would pop up a modal dialog box asking "Do you want to view only securely transmitted web page content?" If the user selected "Yes", all Mixed Content resources would not be loaded; if they selected "No", all resources would be loaded.

Newer IE

Newer IE changes the modal dialog box to a tooltip at the bottom of the page, which is less intrusive to users than before. In addition, image-type Mixed Content will be loaded by default, and other resources such as JavaScript, CSS, etc. will still be loaded based on user selection.

Modern browsers

Modern browsers (Chrome, Firefox, Safari, Microsoft Edge) basically comply with W3C's   Mixed Content   Standardizes Mixed Content into   Optionally-blockable   and Blockable   Two categories:

Optionally-blockable   The Mixed Content class contains resources that are less dangerous and can be tampered with by a middleman. Modern browsers will load such resources by default and print a warning message in the console. Such resources include:

• pass   <img>   Images loaded by the tag (including SVG images);
• pass   <video>   /   <audio>   and   <source>   The video or audio loaded by the tag;
• Prefetched resources;

In addition, all Mixed Content is   Blockable, the browser must prohibit loading such resources. Therefore, in modern browsers, HTTP resources such as JavaScript and CSS in HTTPS pages are not loaded at all, and error information is directly printed in the console.

Mobile browser

What has been said before are all behaviors of desktop browsers. The situation on mobile terminals is more complicated. Currently, most mobile browsers allow the loading of Mixed Content by default. That is to say, for mobile browsers, HTTP resources in HTTPS, whether they are images or JavaScript and CSS, will be loaded by default.

Generally, if you choose HTTPS for the entire site, you must avoid Mixed Content. All resource requests on the page must use the HTTPS protocol to ensure that there are no problems on all platforms and all browsers.

Reasonable use of CSP

CSP, the full name is Content Security Policy, it has a lot of instructions, which are used to implement various functions related to page content security. Here we only introduce two HTTPS-related instructions. For more information, please refer to my previous article "Introduction to Content Security Policy Level 2".

block-all-mixed-content

As mentioned earlier, for images in HTTPS,   Optionally-blockable   HTTP-like resources, which modern browsers load by default. The hijacking of image resources usually does not cause too many problems, but there are some risks. For example, many web page buttons are implemented with images. If the middleman changes these images, it will also interfere with user use.

Through CSP   block-all-mixed-content   Directive that allows the page to enter Strict Mixed Content Checking mode. In this mode, all non-HTTPS resources are not allowed to load. Like all other CSP rules, this directive can be enabled in two ways:

HTTP response header method:

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

<meta>   Label method:

< meta http-equiv = "Content-Security-Policy" content = "block-all-mixed-content" >

upgrade-insecure-requests

The workload of large websites with a long history in migrating to HTTPS is often very huge, especially the step of replacing all resources with HTTPS, which is easy to cause omissions. Even if all code is verified to be correct, there is a good chance that some fields read from the database will contain HTTP links.

And through   upgrade-insecure-requests   This CSP instruction allows the browser to help with this conversion. After enabling this policy, there are two changes:

• All HTTP resources on the page will be replaced with HTTPS addresses before making requests;
• All links on the page will be replaced with HTTPS addresses and redirected after clicking;

Like all other CSP rules, this directive can be enabled in two ways. Please refer to the previous section for the specific format. It should be noted that   upgrade-insecure-requests   Only the protocol part is replaced, so it is only applicable to scenarios where the HTTP/HTTPS domain name and path are exactly the same.

Proper use of HSTS

After the entire website is HTTPS, if the user manually types the website's HTTP address, or clicks on the website's HTTP link from other places, the HTTPS service can only be used by relying on the server's 301/302 redirect. The first HTTP request may be hijacked, causing the request to be unable to reach the server, thus constituting an HTTPS downgrade hijack.

Basic use of HSTS

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

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

max-age, in seconds, is used to tell the browser that within a specified time, this website must be accessed through the HTTPS protocol. That is, for the HTTP address of this website, the browser needs to replace it with HTTPS locally before sending the request.

includeSubDomains, an optional parameter. If this parameter is specified, it means that all subdomains of this website must also be accessed through the HTTPS protocol.

preload, an optional parameter, its function will be introduced later.

The HSTS response header can only be used for HTTPS responses; the website must use the default port 443; and the domain name must be used, not the IP. Moreover, after HSTS is enabled, users cannot choose to ignore the website certificate error.

HSTS Preload List

It can be seen that HSTS can effectively solve the HTTPS downgrade attack, but the first HTTP request before HSTS takes effect cannot avoid being hijacked. In order to solve this problem, browser manufacturers have proposed the HSTS Preload List solution: a built-in list is created, and for domain names in the list, the HTTPS protocol will be used even if the user has not visited them before; the list can be updated regularly.

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

• Have a valid certificate (if using a SHA-1 certificate, the expiration date must be before 2016);
• Redirect all HTTP traffic to HTTPS;
• Make sure HTTPS is enabled on all subdomains;
• 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 above conditions are met, it may not necessarily be included in the HSTS Preload List. For more information, see here. Via Chrome   chrome://net-internals/#hsts   Tool, you can check whether a website is in the Preload List, you can also manually add a domain name to the local Preload List.

Regarding HSTS and HSTS Preload List, my advice is that you should not enable them unless you can ensure that HTTPS services are always provided. Because once HSTS takes effect, if you want to redirect the website to HTTP, the old users will be redirected infinitely. The only way is to change the domain name.

CDN Security

For large websites, they still need to use CDN after migrating the entire website to HTTPS, but they must choose a CDN that supports HTTPS. If you use a third-party CDN, there are some security considerations.

Proper Use of SRI

HTTPS can prevent data from being tampered with during transmission, and a legitimate certificate can also verify the identity of the server. However, if the CDN server is hacked and static files are tampered with on the server, HTTPS will be powerless.

W3C   The SRI (Subresource Integrity) specification can be used to solve this problem. SRI enables the browser to verify whether the resource has been tampered with by specifying the resource's digest signature when the page references the resource. As long as the page is not tampered with, the SRI policy is reliable.

For more information about SRI, please see my previous article "Introduction to Subresource Integrity". SRI is not specific to HTTPS, but if the main page is hijacked, the attacker can easily remove the resource summary, thereby losing 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 the third party, which is also a very risky thing.

CloudFlare developed Keyless SSL technology for this scenario. Instead of giving the certificate private key to a third party, you can provide a real-time computing Key Server. When CDN needs to use the private key, it transmits the necessary parameters to the Key Server through an 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 any third party.

CloudFlare's mechanism has been open sourced. For more information, you can check out this article on their official blog: Keyless SSL: The Nitty Gritty Technical Details.

Well, this article ends here. It should be noted that the CSP, HSTS and SRI strategies mentioned in this article are only supported by the latest browsers. For detailed support, please go to   CanIUse   check. After switching to HTTPS, there is a lot of new work to do in performance optimization. I have written a lot about this part in my previous blog, so I will not repeat it here. I will only say the most important point: since it is HTTPS, the right way is to quickly switch to HTTP/2.

Original text: https://imququ.com/post/sth-about-switch-to-https.html