Support

Admin Tools

#32521 HSTS Header

Posted in ‘Admin Tools for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Admin Tools version
n/a

Latest post by on Saturday, 21 March 2020 18:17 CDT

montejunto
I would like to share only what's happen to me, in order you to do any correction, if you need it too:

On htaccess maker, if i choose HSTS header, it will create this record:

## HSTS Header - See http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000" env=HTTPS
</IfModule>

But in order to be compatible with preload in https://hstspreload.org/: it's needed to change it to:

"max-age=31536000" to "max-age=31536000; includeSubDomains; preload"

Also, i think because of "always" the "env=HTTPS" doesn't work - it gives warnings on https://hstspreload.org.

So, if i change it to "expr=%{HTTPS} == 'on'", it works just fine.

Final code working, in my case:

## HSTS Header - See http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" "expr=%{HTTPS} == 'on'"
</IfModule>

Just to share!

Thanks and keep up the good work!

nicholas
Akeeba Staff
Manager
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.

Nicholas K. Dionysopoulos

Lead Developer and Director

πŸ‡¬πŸ‡·Greek: native πŸ‡¬πŸ‡§English: excellent πŸ‡«πŸ‡·French: basic β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

montejunto
Thank you Nicholas for your quick reply and detailed explanation!

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.


Sorry if I was misunderstood. My goal was not to question how they are generating the code. I was using my particular case, which could possibly be useful.

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.


I fully understand this, but my comment it's only you to consider you to implement it on Admin Tools like options in htaccess maker, for the case of people who don't want to "overwrite" htaccess maker.

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.


Again I didn't mean to generalize but to draw attention, since in my case it didn't work. Perhaps this particular situation of mine can be used by others who, in a similar situation, are unable to make it work. Perhaps this information may appear as a suggestion or additional information. Thank you for the good explanation!

I'm using Admin Tools for several years now, and i'm very satisfied! So, keep up the good work!

nicholas
Akeeba Staff
Manager
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.

Nicholas K. Dionysopoulos

Lead Developer and Director

πŸ‡¬πŸ‡·Greek: native πŸ‡¬πŸ‡§English: excellent πŸ‡«πŸ‡·French: basic β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

System Task
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!