0

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.

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.

  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.