How nginx configures HSTS

Netcraft recently published their research on testing SSL/TLS websites and noted that only 5% of users correctly implemented HTTP Strict Transport Security HSTS.

What is HSTS

HTTPS (SSL and TLS) ensures security during communication between users and websites, making it difficult for attackers to intercept, modify and impersonate. When the user manually enters a domain name or http:// link, the first request to the website is unencrypted, using plain http. The most secure websites immediately send back a redirect directing the user to an https connection. However, a man-in-the-middle attacker may be able to intercept the initial http request and thereby control the user's subsequent responses.

Naturally HSTS came into being to solve this potential security problem. Even if the user enters a domain name or http connection, the browser will strictly upgrade to an https connection.

How HSTS Works

HSTS policies are published in the HTTP response headers sent from secure HTTPS sites.

Strict-Transport-Security: max-age=31536000

When the browser sees this header from an HTTPS site, it knows that the domain name can only be accessed through HTTPS (SSL or TLS). And cache this information to 31536000, which is 1 year.

The optional parameter includeSubDomains tells the browser that the policy applies to all subdomains under the current domain.

Strict-Transport-Security: max-age=31536000; includeSubDomains

nginx configuration HSTS

Set the HSTS response header on the nginx configuration file. The

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

always parameter ensures that all responses set this header, including internally generated error responses. nginx versions earlier than 1.7.5 do not support the always parameter and internally generated error responses do not set this header information.

add_header directive inheritance rules:

nginx configuration block inherits the encapsulation block where the add_header directive is located, so you only need to place the add_header directive in the top-level server block. There is an important exception. If a block contains the add_header directive itself, it will not inherit the header from the enclosing block and you will need to redefine all add_header directives.

server {
    listen 443 ssl;
 
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
 
    # This 'location' block inherits the STS header
    location / {
        root /usr/share/nginx/html;
    }
 
    # Because this 'location' block contains another 'add_header' directive,
    # we must redeclare the STS header
    location /servlet {
        add_header X-Served-By "My Servlet Handler";
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
        proxy_pass http://localhost:8080;
    }
}

Test HTTP Strict Transport Security:

Once the user proposes the HSTS policy, its cache information period is specified by max-age. During this time, the browser will deny access to the web service via unencrypted HTTP and refuse to give exceptions for certificate errors (if the website previously submitted a valid and trusted certificate). If an includeSubDomanis parameter is specified, these restrictions also apply to all subdomains under the current domain.

When you test HSTS, set the max-age time shorter.

Whether each HTTPS response needs to have an STS header:

Our goal is to present the HSTS policy as quickly as possible when the user starts an HTTPS session. If they receive HSTS policies during the session, they are still vulnerable to HTTP hijacking attacks. The browser only has to look at the STS header once, so it's not strictly necessary to add it to every location block and every response. However, just adding it to the homepage or login page may not be enough, if you only add it to the cached response, the client may not see it. Make sure to cover as much of your URL as is reasonable, paying special attention to dynamic content.

HTTP and HTTPS in parallel

Sometimes the website needs to run under HTTP and HTTPS at the same time

server {
    listen  80;
    listen  443 ssl;
    ...
}

Sometimes, http requests need to be redirected to https

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
 
    # Discourage deep links by using a permanent redirect to home page of HTTPS site
    return 301 https://$host;
 
    # Alternatively, redirect all HTTP links to the matching HTTPS page
    # return 301 https://$host$request_uri;
}
 
server {
    listen 443 ssl;
    server_name www.ttlsa.com;
 
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

Enhanced HSTS

Protects the client from HTTP interception from the time it sees the STS header to the declared max-age. However, HSTS is not a perfect solution for HTTP session hijacking. Users are still vulnerable if they access an HSTS-protected website over HTTP:

1. Have never visited the website before

2. Recently revisited Installed its operating system

3. Recently reinstalled its browser

4. Switched to a new browser

5. Switch to a new device such as a mobile phone

6. Delete browser cache

7. Have not visited the site recently and max -age expired

In order to solve this problem, Google insisted on maintaining a "HSTS preload list" site domain name and subdomain name, and submitted it through https://hstspreload.appspot.com/ its domain name. This list of domain names is distributed and hard-coded into major web browsers. Clients accessing domain names in this list will actively use HTTPS and deny access to the site using HTTP.

Once the STS header is set or your domain is submitted to the HSTS preload list, it is impossible to remove it. This is a one-way decision to make your domain name available over HTTPS.

The above is the detailed content of How nginx configures HSTS. For more information, please follow other related articles on the PHP Chinese website!