HTTP HSTs Protocol and Nginx

HTTP HSTs Protocol and Nginx

Guide

Netcraft company recently released their research on the detection of SSL/TLS websites, noting that only 5% of users have correctly implemented HTTP strict transport security hsts. This article describes how Nginx configures HSTs.

What is HSTs

HTTPS (SSL and TLS) ensures that users and Web sites are secure during communication, making it difficult for attackers to intercept, modify, and impersonate them. When a user manually enters a domain name or http://link, the site's first request is unencrypted, using normal HTTP. The most secure Web site is immediately sent back to a redirect user to direct to an HTTPS connection, however, an intermediary attacker could attack to intercept the initial HTTP request, thereby controlling the users ' subsequent reply.

Naturally hsts came into being to solve this potential security problem. Instant user input domain name or HTTP connection, the browser will be strictly upgraded to HTTPS connection.

How the HSTs works

The HSTs policy is published from the HTTP response header that is sent from a secure HTTPS site.

strict-transport-security:max-age=31536000

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

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.

Add_header strict-transport-security "max-age=31536000; Includesubdomains "always;

The always parameter ensures that all responses are set on the header, including internally generated error responses. Nginx versions older than 1.7.5 do not support this always parameter and internally generated error responses do not set this header information.

Add_header directive inheritance rules:

The Nginx configuration block inherits the encapsulation block where the Add_header directive resides, so simply place the Add_header directive in the top-level server block. There is also an important exception, if a block contains the add_header instruction itself, it does not inherit the header from the encapsulation block, and you need to redefine all the 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    Locati On/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 presents the HSTs policy, its cache information period is specified by Max-age. During this time, the browser will deny access to the Web service over unencrypted HTTP and refuse to give an exception certificate error if the site previously submitted a valid, trusted certificate. If you specify a Includesubdomanis parameter, these restrictions also apply to all subdomains under the current domain.

When you test the HSTs, the max-age time is set to a short point.

Whether each HTTPS response requires an STS header:

Our goal is to render the hsts policy as quickly as possible when the user starts HTTPS. If they receive the HSTs policy during the reply, they are still vulnerable to HTTP hijacking attacks. The browser only needs to look at the STS header once, so it is not strictly necessary to add it to each location block and each response. However, adding it only on the homepage or landing page may not be enough, and if you only add the response to the cache, the client may not be able to see it. Ensure as much reasonable coverage as possible to your URLs, paying special attention to dynamic content.

http and HTTPS parallelism

Sometimes web sites need to run simultaneously under HTTP and HTTPS

server {    listen  ;    Listen  443 SSL;    ...}

Sometimes, HTTP requests need to be redirected to HTTPS

server {    listen 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;}

strengthening HSTs

Protects the client from HTTP interception, from which it sees the STS head to the Max-age period of the declaration. However, HSTs is not the perfect solution for HTTP reply hijacking. Users are still vulnerable to attacks if they visit HSTs protected websites via http:

1. have never visited this site before
2. Recently reinstalled its operating system
3. Recently reinstalled its browser
4. Switch to a new browser
5. Switch to a new device such as a mobile phone
6. Delete a browser's cache
7. I haven't visited the station recently and Max-age has expired.

To solve this problem, Google insisted on maintaining a "HSTS preload list" of the site domain name and sub-domain, and submit their domain name through https://hstspreload.appspot.com/. The domain name list is distributed and hard-coded into the main web browser. Client access to the domain name in this list will actively use HTTPS and deny access to the site using HTTP.

Once you have set up the STS header or submitted your domain name to the hsts preload list, it is not possible to delete it. This is a one-way decision to make your domain name available via HTTPS.

Free to provide the latest Linux technology tutorials Books, for open-source technology enthusiasts to do more and better: http://www.linuxprobe.com/

HTTP HSTs Protocol and Nginx