4

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.

Barry Pollard
  • 4,461
  • 14
  • 26

1 Answers1

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

that guy from over there
  • 1,355
  • 10
  • 11
  • 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. –  Feb 05 '15 at 07: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. –  Feb 05 '15 at 07: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 05 '15 at 08: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. –  Feb 05 '15 at 08: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 05 '15 at 09:37
  • And that's the very question I'm asking :-) It would be nice if there was a includeSubDomain="www" option rather than the blanket include. It would depend on me knowing all the https subdomains that I want included but I'm fine with that. – Barry Pollard Feb 05 '15 at 18:05
  • Ah see what you're saying. I was basically forgetting that not including the "includeSubDomains" part didn't mean the top level domain itself wasn't protected as the rest of the header is still being set for the top level domain. And the subdomains that I want to protect are themselves protected separately (possibly with includeSubdomains if I want). Clear now. Being an idiot. Thanks. – Barry Pollard Feb 05 '15 at 18:24
  • cool you sorted that out :D imho, once you get used to use https eveywhere it, is not such an issue to implement it. if you have a well-structured config/change-management and use a reverse proxy infront of every web-service (nginx is a good candidate for this, but i',m biased :) then using https everywhere is part of your daily routine. – that guy from over there Feb 06 '15 at 07:49