HSTS preload list - possible SEO issue for www sites

Question

Let me explain a real world situation here.

I run the website https://www.liloo.ro and I want to enable HSTS (+HSTS preload) for it.

The problem is that in order to submit it to the preload list the main domain has to respond with a HSTS header.

Let me be more precise: In order to submit a site to the preload list and meet the requirements the first redirect has to be to the https version of the main domain.

In my case I can't redirect from http directly to https + www -> I have to redirect first from http to https (serve the main domain name HSTS header here) and redirect once again to https + www

This poses a huge redirect dilution SEO problem (not to mention the fact that chained redirects are not ideal).

So each way I look at this I either have to give up on HSTS preload list or use chained redirects. Neither option looks ideal.

The only possible workaround might be something from the preload list requirements but I don't quite understand what it means:

If you are serving a redirect, that redirect must have the HSTS header, not the page it redirects to.

As far as I know there is no way to serve such thing as a HSTS header when doing a redirect ... but maybe I'm wrong. Any ideas how to solve this issue? ... or should I give up on HSTS preload list altogether because my site is www only?

I can't just switch from www to non-www at this point... I know it would have been the "easy" solution.

Any idea - much appreciated. I noticed this thread Adding HSTS http headers on domain root during redirect to www subdomain in web.config ...but I doubt it solves the issue (+ I'm using nginx)

Answer 1

I am really thankful you posted this, because I have exactly the same issue, i.e., http://DOMAIN redirects directly to https://www.DOMAIN, combining the redirect to HTTPS and the one to the www subdomain.

I know it would have been the "easy" solution.

Note that there are reasons to use a subdomain like www, as has been discussed on several occasions already, and so this choice is completely understandable.

However, HSTS has no way (at least not yet) to combine the two redirects: It can only forward directly to HTTPS. I suppose that if the HSTS preload site detects that this is not what the plain HTTP server itself does, then enforcing a "307 internal redirect" to just HTTPS is not admissible. (As far as I can tell, this requirement is not explicitly stated on hstspreload.org, but can only be found out by actually trying to set up the HSTS preload.)

I have no full answer to your question, but I can provide a bit more information on a few points you raise:

If you are serving a redirect, that redirect must have the HSTS header, not the page it redirects to.

Please note the exact (current) quote from hstspreload.org:

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).

This is relevant for the following point:

As far as I know there is no way to serve such thing as a HSTS header when doing a redirect ...

It is completely possible that a HTTP redirect response also has an HSTS header. This only means that the HTTP redirect response also contains a Strict-Transport-Security header field with suitable parameters. For example, using SWI-Prolog as HTTP server, you can emit such responses like this:

?- http_status_reply(moved('https://stackoverflow.com'), current_output,
     [strict_transport_security('max-age=63072000; includeSubdomains')], Code).

yielding:

HTTP/1.1 301 Moved Permanently
Date: Sun, 12 Feb 2017 10:04:55 GMT
Location: https://stackoverflow.com
Strict-Transport-Security: max-age=63072000; includeSubdomains
Content-Length: 366
Content-Type: text/html; charset=UTF-8

etc.

Note that this header field is only admissible when TLS is already being used (otherwise, an attacker could force traffic to a different port via a connection that is not authenticated!). In fact, the header must not occur in the HTTP→HTTPS redirect, because it uses an unauthenticated connection, and if it (incorrectly) does occur over plain HTTP, the client must ignore it.

Now to the actual main point of your question:

This poses a huge redirect dilution SEO problem (not to mention the fact that chained redirects are not ideal).

I completely agree that the chained redirects are far from ideal, and there seems to be no way around this with such (common!) setups as ours, at least not currently.

However, my personal hope is that the impact of the additional redirect will not impact your site's rank a lot: Theoretically, once a search engine sees that your site is in the HSTS preload list, all it should care for is the HTTPS version of it (because that's also what browers that support HSTS preload will do!). Therefore, you end up with only a single redirect, namely the https://DOMAIN→https://www.DOMAIN one, which should be rather comparable to your current situation. At least that's my somewhat naive hope. In this redirect, make sure that the HSTS header is included, since this is a requirement to get into the preload list. Of course the exact configuration details depend on your concrete web server.

Also, note that you cannot reinstate the original redirect chain even after you have made it into the HSTS preload list. This is because the Continued requirements section states:

You must make sure your site continues to satisfy the submission requirements at all times.