Detailed explanation of how to enable HSTS in nginx to force the browser to redirect to HTTPS access

In the previous article, we have implemented local node service access using https. The effect of the previous article can be seen as follows:

But if we use http to access it now, we cannot access it. As shown in the following figure:

So the first thing I need to do now is to use nginx configuration. When the user enters an http request in the browser, use nginx to redirect it to https. So now we need to make a simple nginx redirect function.

Therefore, we need to add the following redirection configuration in our nginx:

server {
 listen xxx.abc.com;
 server_name xxx.abc.com;
 rewrite ^/(.*)$ https://$host$1 permanent;
}

Therefore, the main configuration code of nginx is as follows:

server {
 listen xxx.abc.com;
 server_name xxx.abc.com;
 rewrite ^/(.*)$ https://$host$1 permanent;
}
server {
 listen 443 ssl;
 server_name xxx.abc.com;

 ssl_certificate cert/server.crt;
 ssl_certificate_key cert/server.key;

 ssl_session_cache shared:SSL:1m;
 ssl_session_timeout 5m;

 ssl_ciphers HIGH:!aNULL:!MD5;
 ssl_prefer_server_ciphers on;

 location / {
 proxy_pass http://localhost:3001;
 }
}

After the above configuration, we need to restart nginx to take effect. When we enter the domain name http://xxx.abc.com in the browser, it will automatically redirect to https://xxx.abc.com/. Let's take a look at the requests on our network. There are 2 requests, as shown below:

As can be seen from the above request, the browser will first initiate an http request to the website (http://xxx.abc.com), and after receiving a redirect response, it will initiate an https request and obtain the final response content. For users, its operation is transparent and the user experience is good, but there will be a plaintext http request and redirection before the https link. Then the attacker can hijack the http request in a man-in-the-middle manner. to carry out subsequent attacks. For example, eavesdropping on data. Tampering with requests or responses, jumping to phishing websites, etc. Therefore, http requests are not secure enough, so in recent years all websites must be accessed via https.

Let's take hijacking http requests and jumping to phishing websites as an example to see what the general hijacking process looks like.

The steps are as follows:
1. The browser will initiate an http request (such as http://xxx.abc.com). After the request is sent, the attacker will hijack the http request as a man-in-the-middle.
2. After the attacker hijacks the http request, he will forward the current request to the phishing website (such as http://xxx.yyy.com).
3. The phishing website will return fake web page content.
4. Finally, the attacker returns the fake web page content to the browser.

As shown above, the http request is not redirected to the https website at all. Instead, the attacker directly hijacks the http request and eventually returns the phishing website to the browser. Therefore, if HTTP redirection is used directly, there will be a problem of HTTP request in plain text. Therefore, it is not safe to use HTTP redirection directly. Therefore, HSTS appears to solve this problem. Let’s take a look at HSTS.

2. Understanding HSTS

There is a security problem in redirecting http to https using the redirect method mentioned above, because there will be an http plaintext request before redirecting https, so it is easy for attackers to hijack the http request. Therefore, now we want the browser to directly convert it into an https request when the user's browser initiates an http request. Then request the page through https, so it is generally difficult for attackers to attack. We can look at the following schematic diagram, as shown below:

The steps can be understood as follows:

1. When the user enters http://xxx.abc.com in the browser, the browser knows that the domain name needs to use https for communication.
2. Therefore, the browser directly initiates an https request to the website (such as https://xxx.abc.com).
3. The website returns the response content.

So the question now is, how does the browser know that the domain name needs to use https? So at this time we have HSTS.

What is HSTS?

The full name of HSTS is HTTP Strict-Transport-Security. It is an Internet security policy mechanism released by the International Internet Engineering Organization IETF. Websites that adopt the HSTS policy will ensure that browsers always connect to the https encrypted version of the website. Users do not need to manually enter the encrypted address in the URI address bar to reduce the risk of session hijacking.

The basic syntax of HSTS is as follows:

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

max-age is a required parameter. It is a value in seconds. It represents the expiration time of the HSTS Header and is generally set to 1 year, or 31536000 seconds.
includeSubDomains is an optional parameter. If this parameter is set, it means that HSTS protection is enabled for the current domain and its subdomains.
preload is an optional parameter and is only needed when you apply to add your domain name to the browser's built-in list.

Next, let's take a look at how Baidu handles this. First, we enter http://www.baidu.com/ in the browser URI and press Enter. The browser will automatically convert it into a request like https://www.baidu.com/. However, when we use the Chrome browser to view the network request, we can see that two requests will be sent as follows:

The second is an https request, as shown below:

We can see above that the status code of the first request is 307, and the request header has the following mark "Provisional headers are shown", which means that the browser intercepted the request and the request was not sent out. Therefore, the browser finds that the domain name needs to be requested using https, so it sends a second https request.

Configure HSTS in nginx

Set the HSTS response header in the nginx configuration file. The code is as follows:

add_header Strict-Transport-Security "max-age=172800; includeSubDomains"

Therefore, the configuration of nginx is as follows:

server {
 listen xxx.abc.com;
 server_name xxx.abc.com;
 rewrite ^/(.*)$ https://$host$1 permanent;
}
server {
 listen 443 ssl;
 server_name xxx.abc.com;
 add_header Strict-Transport-Security "max-age=172800; includeSubDomains";
 ssl_certificate cert/server.crt;
 ssl_certificate_key cert/server.key;

 ssl_session_cache shared:SSL:1m;
 ssl_session_timeout 5m;

 ssl_ciphers HIGH:!aNULL:!MD5;
 ssl_prefer_server_ciphers on;

 location / {
 proxy_pass http://localhost:3001;
 }
}

Then save the nginx configuration and restart it.

After I restart, when I use https to access my website for the first time, nginx will tell the client browser that if the user enters http in the future, the browser should also access my nginx server using https, as shown below:

However, if nginx is restarted and http is used for the first access, although it jumps, HSTS is not used, because HSTS will only be used when jumping to https. But when I enter http again, there will be a 307 status code and a prompt like "Provisional headers are shown".

Understanding HSTS Preload List

Although HSTS can solve the downgrade attack of HTTPS, it still cannot avoid the problem of http request being hijacked for the first http request before HSTS takes effect. For example, if we clear the browser cache for the first time and then use http request for the first time, the first http is also transmitted in plain text. When jumping to https, HSTS will be used. In the future, as long as the browser cache is not cleared and nginx is not restarted, HSTS protection will be used. Therefore, in order to solve the problem of the first http request, browser manufacturers have proposed the HSTS Preload List solution, which has a built-in table that can be updated regularly. For domain names in the list, even if the user has not visited them before, they will be requested using the https protocol.

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:

1. Have a valid certificate (if using a SHA-1 certificate, the expiration date must be earlier than 2016);

2. Redirect all HTTP traffic to HTTPS;
3. Make sure HTTPS is enabled on all subdomains;
4. Output HSTS response header:
5. max-age cannot be less than 18 weeks (10886400 seconds);
6. The includeSubdomains parameter must be specified;
7. The preload parameter must be specified;

Even if all the above conditions are met, you may not be included in the HSTS Preload List. For more information, please visit: https://hstspreload.org/.

Through Chrome's chrome://net-internals/#hsts tool, you can check whether a website is in the PreloadList, and you can also manually add a domain name to the local Preload List.

HSTS Disadvantages

HSTS is not a perfect solution to HTTP session hijacking. The first time a user visits a website, it is not protected by HSTS. This is because the browser has not received HSTS during the first visit, so it is still possible to access via plaintext HTTP.

If a user accesses a website protected by HSTS via HTTP, downgrade hijacking may occur in the following situations:

1. Never visited this website before.
2. Recently reinstalled their operating system.
3. Recently reinstalled their browser.
4. Switch to a new browser.
5. Delete your browser's cache.
6. The site has not been visited recently and the max-age has expired.
To solve this problem, you can use the HSTS Preload List method introduced above.

HSTS-supported browsers

Currently, mainstream browsers already support HSTS features. For details, please refer to the following list:

Google Chrome 4 and above
Firefox 4 and above
Opera 12 and above
Safari since OS X Mavericks
Internet Explorer and above

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.