0

My website makes use of Universal SSL from CloudFlare and I would like to have the browser redirect to HTTPS automatically. However, as not all browsers support the type of SSL cloudflare uses, I don't want to outright force SSL. So HSTS seems to be a good option. However, when I test it in my browser it doesn't appear to be working as I expect it to.

In my configuration file for the site, I have this line:

server {
    ...
    listen 443 ssl;
    add_header Strict-Transport-Security max-age=63072000;
    ...
}

And it shows up in the response headers:

Strict-Transport-Security: max-age=63072000

However Firefox 35 and Chrome 41 on Windows 10 and OS X 10.10.3 will still navigate the site on HTTP without redirecting to HTTPS.

I am using NGINX Version 1.7.3 running on CentOS 7.

ecnepsnai
  • 234
  • 3
  • 16
  • Using HSTS sounds like a very strange approach when you don't want to force SSL, since the purpose of HSTS is to force SSL. – kasperd Feb 16 '15 at 08:49

2 Answers2

6

The STS response header is only effective on secure schemes. The client must visit the https page at least once to get a STS entry in the HSTS cache.

The spec suggests that servers SHOULD redirect to https from HTTP, but that is not always feasible. So you could try to sniff unsupported User-Agent at the back-end, and only issue a redirect if the UA is not blacklisted.

See section 7.2 of RFC 6797 for more background information:

7.2. HTTP Request Type
If an HSTS Host receives an HTTP request message over a non-secure transport, it SHOULD send an HTTP response message containing a status code indicating a permanent redirect, such as status code 301 (Section 10.3.2 of [RFC2616]), and a Location header field value containing either the HTTP request's original Effective Request URI (see Section 9 ("Constructing an Effective Request URI")) altered as necessary to have a URI scheme of "https", or a URI generated according to local policy with a URI scheme of "https".

NOTE: The above behavior is a "SHOULD" rather than a "MUST" due to:

  • Risks in server-side non-secure-to-secure redirects [OWASP-TLSGuide].
  • Site deployment characteristics. For example, a site that incorporates third-party components may not behave correctly when doing server-side non-secure-to-secure redirects in the case of being accessed over non-secure transport but does behave correctly when accessed uniformly over secure transport. The latter is the case given an HSTS-capable UA that has already noted the site as a Known HSTS Host (by whatever means, e.g., prior interaction or UA configuration). An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.
Community
  • 1
Rob W
  • 371
  • 2
  • 5
3

Not an answer per se, but the reason you're not allowed to set Strict-Transport-Security on an insecure connection is that doing so would allow a MITM attacker--the very threat for which HSTS was designed--to block access to any site which did not actually support SSL.

  • 1
    Wouldn't an attacker achieve almost the same result by getting an ordinary HTTP redirect cached by the browser? – kasperd Feb 16 '15 at 08:46