5

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:

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.

Improve this question

1 Answer 1

Reset to default
2

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

Improve this answer
8
  • Yes but not setting the includeSubDomain opens the top level domain to a man in the middle attack if anyone uses that address and surely goes against best practice for configuring HSTS? I guess in theory as long as they visit that site once from a non-compromised site then they'll have the flag set on the www domain. But does seem to limit the usefulness of the includeSubDomain flag for top level domains for this very common scenario.
    – BazzaDP
    Feb 5, 2015 at 7:50
  • And btw I'm not concerned with setting the HSTS header and redirect on sub domains as that's relatively simple and should be done anyway. The issue with internal sites is not a cert issuance issue - though I'd prefer not to have to put the main company private key on every little web server we use, so a wildcard cert is not the answer but own CA works. It's more an upgrade nightmare for all website/web services - some of which may not even support https. And yes after that there is the administrative issue of replacing expired keys.. etc. Just seems overkill for a lot of internal sites.
    – BazzaDP
    Feb 5, 2015 at 7:58
  • Some would argue that an insider MITM attack is much more likely to happen on a large scale than an external MITM. So I do not think it is 'overkill' to use HTTPS on internal sites..
    – Michael
    Feb 5, 2015 at 8:15
  • Potentially, and an interesting point. However 1) companies have a bit more control over the equipment they allow on their network (though whether they do anything with that control like patch and monitor for security issues is another matter) and 2) the secure websites open to risk from MITM attacks should be secured with https even when internal - not arguing that. I'm just saying lots of smaller, less critical or less sensitive internal websites don't necessarily need https. Maybe the answer is https everywhere but that's not a quick job and until then this flag is a risk thing to turn on.
    – BazzaDP
    Feb 5, 2015 at 8:30
  • Fair point, back to your first comment then: "Yes but not setting the includeSubDomain opens the top level domain to a man in the middle attack". How does not setting the includeSubDomain flag open the top level domain to MITM attacks? If you make sure to set your cookies per subdomain, there shouldn't be an issue. Or am I missing something?
    – Michael
    Feb 5, 2015 at 9:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .