Support

I'd like to say upfront that I don't just blindly copy code into the .htaccess Maker. I actually get to read up on each web server / HTTP protocol feature, consult web security blogs for the more nuanced repercussions of each possible setting, spend a great deal of time weighing convenience, security and mass distribution, run several tests on different local and live sites and then – ONLY then – do I add something the .htaccess Maker. That is to say, I'm not unaware of the points you make. I have weighed them and I can tell you why I took the decisions I did.

includeSubdomains is not something we can add in mass distributed software. Many of our clients have use cases where certain subdomains need not be HTTPS, e.g. short-lived landing pages. Sure, yeah, there's Let's Encrypt. It's one thing for our clients being able to choose to use Let's Encrypt to add HTTPS to their short-lived landing pages and a different thing FORCING THEM to do so just so their main site can get HSTS.

The preload flag is proprietary and only used for inclusion in Chrome's built-in HSTS list. It also comes with a lot of requirements, gotchas and caveats. It's definitely not something that we should add to a mass-distributed software. And, anyway, since we can't include includeSubdomains this point is moot.

Regarding env=HTTPS, I'm sorry to say, but you are wrong. There's a reason it's there. The HSTS header must be always sent for HTTPS requests. Conversly, an HTTP request MUST NOT include an HSTS header; that's invalid. On most web servers this is accomplished by using env=HTTPS.

Your server is not set up correctly. Namely: it sits behind a reverse proxy or TLS terminator which does not forward the protocol to the Apache web server handling the request. As a result, even though the request is served under HTTPS the web server does not know it. That's why you had to use expr=%{HTTPS} == 'on'. Unfortunately, your use case belongs to a stark minority and doesn't work on most other sites. Since Admin Tools is a mass distributed extension it cannot include an option that only works on a stark minority of sites. Hence our default choice of env=HTTPS.

I am saying this not directed at you but as a means to give context to me saying no to a set of options (which, by the way, is insanely harder than saying yes).

Assuming that you're not a pilot, take a look at a high-res photo of a jet airliner's cockpit. That interface looks intimidating. You will think that you shouldn't touch it unless you receive thousands of hours of training before you even come close to it. To an expert it's not that intimidating at all; it's a pretty standard interface with all the necessary controls and readouts.

Now take a look at a commercial drone's interface. Much simpler, much more intuitive and it makes you think that after a stark few hours of training you can master it. An expert aviator would find it too simple and probably gripe about its lack of necessary controls and readouts.

Do you see where I'm going with this? Both are aviation product. The former is targeting corporations employing highly trained experts to use it; the latter is aimed at consumers. One is pretty much a bespoke product, the other is a mass market product.

Our software is mass-market, it's not an expert product. Experts are perfectly capable of and content in pursuing the arcane art of manually editing configuration file with cryptic options, having a solid grasp of the subtle effects their changes have. They don't need a GUI. The mass market users, however, don't have that knowledge, don't have the time to acquire that knowledge nor do they have the money to hire an expert. Their needs must be met as automatically as possible with an interface that implies they can master it in a matter of hours, not a matter of years upon years.

So, when it comes to mass distributed software it's crucial to know when to say no to the proliferation of options. In one extreme we have WordPress which doesn't give options even for basic features, on the other extreme we have Joomla which gives options for arcane options that should best be left for template overrides. We try to be somewhere in the middle. This is hard. It requires saying no to a lot of things. For every option that's implemented in the .htaccess Maker there are six to ten that were killed off anywhere from the initial consideration to the implementation stage. if I had implemented everything I had in mind the .htaccess Maker would be impossible to use by anyone except the experts... who don't actually need it. Oops.

That is the context under which I consider the various options for HSTS.

As I said, there are very good reasons not to add HSTS flags by default in a mass-market product. Likewise, addressing the badly configured servers is also something that cannot be done by default. Adding a whooping 3 more options to an already crowded page just to support the most rare use cases works against the core mission of the .htaccess Maker which is making sensible security accessible to the non-experts.

If you really need to apply HSTS to your subdomains and submit your site for HSTS preloading in Chrome then yes, by all means, do disable HSTS in .htaccess Maker and use the custom code textbox to enter your customized version of the HSTS feature. That's the whole point of the custom code boxes: if you want customization beyond the restrictions of mass-market compromises you are able to turn off the feature and put your custom code in there. That's the best way we can serve, at the same time, the inexperienced and the expert users with the same product.