Problems using HSTS header at top level domain with includeSubdomains

Let's say I run a company "Example Inc" and have a website at:

https://www.example.com

Now because I'm security conscience I'm using https and would like to set the HSTS header to force its use. I'd also includeSubdomains for a long time, let's say a year.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Now I'm also a good website owner so I set up the following with 301 redirects to above site:

• http://www.example.com
• http://example.com
• https://example.com

The last one also has the HSTS header as well as its a https site.

This, as I understand it, is the recommended set up for running a https website (plus lots of other settings obviously) and would be fairly common.

So far so good.

Now internally, on the company intranet, and not available on the Internet, I have loads of servers and use the example.com domain. So I have:

• machine1.example.com
• machine2.example.com ...etc

Now supposing some of these machines run web servers and not all of them are https.

Does this not mean if any of my employees happened to visit https://example.com then their browser will set the HSTS header and will refuse to go to http for any sub domains and so can no longer access some of those internal http-only webservers?

What's the way around this?

Should I compromise my external website security by not using the includeSubDomains setting? At least not on the https://example.com site? That seems wrong to compromise external security for an internal issue.

Should I force all my internal apps to be https too? That's easier said than done.

Should I use a different domain internally? E.g. machine1.intraexample.com? Seems a waste of a domain and some items (e.g. Email server) will need to be on the main domain, though possibly they could be limited to https only web servers if they even need to run them at all.

Any other thoughts?

Also, think this could cause a big problem for a company and possibly should be highlighted more in the spec and elsewhere. Many website owners don't have separate config for the non-www version and so could inadvertently set the includeSubDomain flag on the top level domain. It was only when thinking of this scenario before implementation that I avoided this. I will set the expiry very low initially (one day) to iron out these issues as well which also could be suggested more forcefully IMHO. This could easily have been missed and caused weird problems for potentially a lot of users.

Edit June 2015 And here's a real world example of a site getting this very thing wrong: https://github.com/NuGet/NuGetGallery/issues/2535

Edit October 2015 An article that suggests you really should use includeSubDomains at TLD to address flaws in cookies: http://www.kb.cert.org/vuls/id/804060. This is true (a hacker with DNS access could otherwise create a fictious sub-domain and use this to set a cookie at TLD level). However above risk of self DoSing internal HTTP-only sites still exists with that, and this will only provide protection of you go to TLD or preload HSTS.

Solution 1:

the approach not serving the includeSubDomains - flag means a little more work and discipline but is not considered harmful, especially when you have a reason to do so.

• you can set the HSTS - header explicitely on every external HTTPS - server w/out includeSubDomains.

• furthermore, make sure every HTTPS - servers has additional a HTTP -> HTTPS - redirect.

but best practice would be to use https-traffic for internal websites too. you could either use your own CA or a wildcard-cert that is not that expensive anymore