Shulou(Shulou.com)06/03 Report--

This article mainly explains "the principle of enabling HTTPS". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "the principle of enabling HTTPS".

Understand Mixed Content

The HTTP resources loaded in HTTPS pages are called Mixed Content (mixed content), and different browsers have different rules for dealing with Mixed Content.

Early IE

When early IE found a Mixed Content request, it popped up, "do you want to view only securely delivered web content?" "in such a modal dialog box, once the user selects" Yes ", all Mixed Content resources are not loaded; select" No "and all resources are loaded.

Relatively new IE

Newer IE changes the modal dialog box to the prompt bar at the bottom of the page, which is not as disturbing to the user as before. And the image class Mixed Content will be loaded by default, and other resources such as JavaScript and CSS will be loaded according to the user's choice.

Modern browser

Modern browsers (Chrome, Firefox, Safari, Microsoft Edge) basically follow the W3C Mixed Content specification, dividing Mixed Content into Optionally-blockable and Blockable:

The Optionally-blockable class Mixed Content contains resources that are less dangerous and can be tampered with by middlemen. Modern browsers load such resources by default and print warnings on the console. Such resources include:

Pass through

Tag-loaded pictures (including SVG pictures)

Video or audio loaded through / and tags

Pre-read (Prefetched) resources

In addition, all Mixed Content are Blockable, and browsers must disable loading of such resources. Therefore, in modern browsers, JavaScript, CSS and other HTTP resources in HTTPS pages are not loaded and error messages are printed directly in the console.

Mobile browser

All the above is the behavior of desktop browsers. Mobile browsers are complicated. Most mobile browsers allow Mixed Content to be loaded by default. In other words, for mobile browsers, HTTP resources in HTTPS, whether they are images or JavaScript or CSS, are loaded by default.

Generally, if you choose the full site HTTPS, you should avoid Mixed Content. All resource requests on the page follow the HTTPS protocol to ensure that there are no problems under all browsers on all platforms.

Rational use of CSP

CSP, whose full name is Content Security Policy, has a lot of instructions to implement a variety of functions related to page content security. Here are only two instructions related to HTTPS. For more information, you can see "introduction to Content Security Policy Level 2" I wrote earlier.

Block-all-mixed-content

As mentioned earlier, modern browsers load Optionally-blockable-like HTTP resources such as pictures in HTTPS by default. Image resources are hijacked, usually not too big a problem, but there are also some risks, such as many web buttons are implemented with pictures, the middleman to change these pictures, will also interfere with the use of users.

Through the block-all-mixed-content directive of CSP, you can put the page into Strict Mixed Content Checking mode of mixed content. In this mode, all non-HTTPS resources are not allowed to be loaded. As with all other CSP rules, this directive can be enabled in two ways:

HTTP response header mode:

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

Label method:

Upgrade-insecure-requests

Large stations with a long history often have a huge workload in the process of migrating to HTTPS, especially the step of replacing all resources with HTTPS, which is prone to omissions. Even if all the code confirms that there is no problem, it is likely that there are HTTP links in some fields read from the database.

Through the CSP instruction upgrade-insecure-requests, you can ask the browser to help with this conversion. When this policy is enabled, there are two changes:

All HTTP resources on the page will be replaced with the HTTPS address before initiating the request.

All the intra-site links on the page will be replaced with the HTTPS address after clicking.

Like all other CSP rules, there are two ways to enable this directive. Please refer to the previous section for the format. It should be noted that upgrade-insecure-requests only replaces part of the protocol, so it only applies to scenarios where the HTTP/HTTPS domain name and path are exactly the same.

Rational use of HSTS

After the HTTPS of the whole site, if users manually type in the HTTP address of the site, or click on the HTTP link of the site from somewhere else, they rely on the server 301Maple 302 to jump to use the HTTPS service. The first HTTP request may be hijacked, resulting in the request can not reach the server, which constitutes a HTTPS degraded hijacking.

Basic use of HSTS

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

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

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

IncludeSubDomains, an optional parameter, if specified, indicates that all subdomains of the site must also be accessed through the HTTPS protocol.

Preload, optional parameter, which will be described later.

The HSTS response header can only be used for HTTPS responses; the website must use the default port 443; the domain name must be used, not IP. And after HSTS is enabled, the user cannot choose to ignore it once the website certificate is wrong.

HSTS Preload List

You can see that HSTS can solve the HTTPS degradation attack very well, but for the first HTTP request before HSTS takes effect, it is still impossible to avoid being hijacked. In order to solve this problem, browser manufacturers have put forward a HSTS Preload List solution: a list is built in, and the HTTPS protocol will be used for the domain names in the list, even if the user has not visited it 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 first need to meet the following conditions:

Have a valid certificate (if a SHA-1 certificate is used, the expiration date must be earlier than 2016)

Redirect all HTTP traffic to HTTPS

Ensure that all subdomains have HTTPS enabled

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, you may not be able to enter HSTS Preload List. More information can be found here. Through Chrome's chrome://net-internals/#hsts tool, you can query whether a website is in Preload List or manually add a domain name to the native Preload List.

For HSTS and HSTS Preload List, my advice is not to enable HTTPS services as long as you are not sure to provide them forever. Because once HSTS takes effect, you want to redirect the site to HTTP, the old users will be infinitely redirected, the only way is to change the domain name.

CDN security

For large stations, you still have to use CDN after the whole site is migrated to HTTPS, but you have to choose CDN that supports HTTPS. If you use a third-party CDN, there are some security considerations.

Rational use of SRI

HTTPS can prevent data from being tampered with in transmission, and legitimate certificates can also play a role in verifying the identity of the server, but if the CDN server is invaded, resulting in static files being tampered with on the server, HTTPS is powerless.

The W3C SRI (Subresource Integrity) specification can be used to solve this problem. SRI enables browsers to verify that the resource has been tampered with by specifying the digest signature of the resource when the page references it. As long as the page is not tampered with, the SRI strategy is reliable.

For more information about SRI, please see "introduction to Subresource Integrity" I wrote earlier. SRI is not dedicated to HTTPS, but if the main page is hijacked, an attacker can easily remove the resource summary and lose the browser's SRI verification mechanism.

Learn about Keyless SSL

Another problem is that when using third-party CDN's HTTPS service, 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 a very risky thing.

CloudFlare has 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 instead. When the private key is to be used in CDN, the necessary parameters are passed to Key Server through the encrypted channel, and the result is calculated and returned by Key Server. Throughout the process, the private key is kept in its own Key Server and will not be exposed to a third party.

Thank you for your reading, the above is the content of "the principle of enabling HTTPS", after the study of this article, I believe you have a deeper understanding of the principle of enabling HTTPS, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.