CODEWITHSUNDEEP
httpsslencryptionhttpshsts
Craig Lewis
Craig Lewis

Reputation: 3

Why does SSL Labs test say that HSTS is enabled when the header is sent over HTTP, but not when sent over HTTPS?

I'm trying to configure HSTS on my server. I've noticed that the test on SSLLabs.com will tell me that HSTS has been enabled if I send the HSTS header over the initial unencrypted HTTP connection. This, however, is in violation of the HSTS spec according to RFC-6797 Section 7.2, which clearly states that you should NOT send this header over an unencrypted connection.

On the other hand, if my server sends out that HSTS header ONLY after doing a 302 redirect from HTTP to HTTPS, which is precisely what the official HSTS spec says you SHOULD do, then SSL Labs does NOT acknowledge that I have HSTS enabled.

So what am I missing here? What's the actual correct way to do this?

If you want to see what I'm talking about, the site in question is nightowlcircusarts.com

You can view the unencrypted headers using curl with this bash command:

curl -I http://www.nightowlcircusarts.com/

Or change that http to https to see the encrypted headers:

curl -I https://www.nightowlcircusarts.com/

Currently, I have it configured to ONLY send that header over TLS, and not without it, as the HSTS spec says to do. But you'll see that the SSL Labs test still says I DON'T have HSTS enabled: https://www.ssllabs.com/ssltest/analyze.html?d=nightowlcircusarts.com

Upvotes: 0

Views: 901

Answers (1)

Barry Pollard
Barry Pollard

Reputation: 45895

Well for a start ssllabs does not scan sites on unencrypted connections - only on encrypted ones (https). So it will not tell you that you have it enabled on http.

Your issue is that nightowlcircusarts.com and www.nightowlcircusarts.com are two different sites and you are only setting it on the latter but scanning it on the former:

Now the scan results do show, at the bottom, that the bare domain does redirect to the www version, but ssllabs is tasked with testing the SSL/TLS connection (which happens before redirects) so it deliberately does not follow redirects and instead reports the SSL/TLS connection config. It expects you to scan the redirect site separately - precisely for use cases like this where you have it set up differently!

I guess when you "send the HSTS header over the initial unencrypted HTTP connection", what you are actually doing is setting it everywhere (including the bare domain over https) which is why you thought it "worked" when you did that.

It is permissible (and expected!) to set HSTS over https-to-https redirects. And in fact your specific example is covered in the RFC in section 11.4.1.

Btw adding HSTS to the bare domain is best practice, but do ensure your entire domain is only ever served over https. If you have one subsite (e.g. blog.example.com) or also use this for non public sites which are not yet secured (e.g. intranet.example.com) then this can cause problems. In this case you could add HSTS to bare domain but without the includeSubdomain option - though that will not give you the full protection of HSTS.

Lastly, if checking out the various security Headers of a site rather than the SSL/TLS config then https://securityheaders.io is a great site and a lot quicker to run than the whole set of SSL/TLS tests that ssllabs does:

Note these two sites check for different things, so one us not a replacement of another (big fan of both!), but some settings (HSTS and HPKP) are shown by both. And while on the subject be very careful with HPKP (I am not a fan and do not think it should be widely used at all).

Upvotes: 1

Related Questions