HSTS with canonical URL redirect in nginx

Question

I was using the nginx configuration taken from this post to implement redirect from http://(www.)example.com -> https://example.com:

server {
    server_name www.example.com example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    <possibly other ssl directives if you have a separate cert and key for www>
    server_name www.example.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    ssl_certificate /path/to/server.cert;
    ssl_certificate_key /path/to/server.key;
    server_name example.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    <locations for processing requests>
}

I'd like to add HSTS to this, so am following the nginx documentation, which amounts to adding

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

to both SSL server blocks (as done above).

TLDR: Is the STS header in the second server block necessary?

However I was doing some reading around the topic, especially this blog post which seemed to think that:

...if your canonical URL is www.example.com, the includeSubDomains token will not protect example.com as this is not a subdomain of www.example.com. A solution is to make a request from www.example.com to an uncached resource on https:// example.com, e.g. a 1px image, and make sure that https:// example.com sets the HSTS header.

I guess this is correct, as if you go straight to canonical https://www.example.com then it will only protect http://*.www.example.com.

However this doesn't appear an issue if your canonical URL is https://example.com and you use includeSubDomains. I tested it on Chrome and it did the following http://www.example.com (307) -> https://www.example.com (301) -> https://example.com.

So is the Strict-Transport-Security header in the second listen 443 ssl www.example.com block necessary? As a direct request to https://www.example.com would be SSL anyway, and it would pick up the STS includeSubDomains header on redirect from the third server block, protecting http://www.example.com in the future.

score 1 · Accepted Answer · answered Dec 31 '17 at 13:02

1

Yes, it is preferred to have the STS header in both server blocks, for the reason you wrote in your question.

Looking at it the other way, there is no harm in specifying the header in the example.com server either.

answered Dec 31 '17 at 13:02

Tero Kilkanen

37,584

I don't think it will validate for preloading unless it is in the example.com, as well as subdomains – Colt Dec 31 '17 at 14:37
What do you mean by preloading here? – Tero Kilkanen Dec 31 '17 at 15:18
HSTS preloading is where browsers hard code the URLs of HSTS sites into the browser, thereby ensuring that there is NEVER a non-HTTPS communication with the site. In order to be included, the HSTS header must be included on the base domain. Here is the hstspreload.org landing page with more details. – Colt Dec 31 '17 at 15:49
1

Also, preloading will require that http://example.com (HTTP) immediately redirect to https://example.com (HTTPS) before adding the www subdomain, that is, before redirecting to https://www.example.com. The extra redirect is required to ensure that any browser which supports HSTS will record the HSTS entry for the top level domain, not just the subdomain. – Colt Dec 31 '17 at 16:00
All of this, of course, is only relevant if the preload header is desired, which is why it is just offered as a comment to your answer. Although not presently preventing an A+ rating, Qualys' SSL Server Test is now at least checking for preloading. – Colt Dec 31 '17 at 16:06
@Colt The preload will be required eventually. I was looking through the hstspreload.org site and it seemed to answer my question: "If you are serving an additional redirect from your HTTPS site, that redirect must still have the HSTS header (rather than the page it redirects to)." So the header in server #2 stays. – Heuriskos Dec 31 '17 at 18:30
That is correct. In addition to being required to make the two-step redirect described above, the only other caveat is that an HTTP "site" that exists just to redirect to the HTTPS version shoud NOT have the header. You can also use the hstspreload.org site to "test" your setup. As long as you don't have preload directive set it will not attempt to submit your site, but it will tell you exactly what you need to do to be compliant (including later adding the preload directive). – Colt Dec 31 '17 at 18:46
Thanks @Colt for the information, I didn't know the details of preloading, only that the mechanism exists. I have to keep it in mind with future projects. – Tero Kilkanen Jan 01 '18 at 02:52
I think adding the quote"If you are serving an additional redirect from your HTTPS site, that redirect must still have the HSTS header (rather than the page it redirects to)." and a link to hstspreload.org would enhance the answer. – Heuriskos Jan 01 '18 at 13:40

HSTS with canonical URL redirect in nginx

1 Answers1