Selectively disable HSTS?

[WebbleVince]

Hi,

I was wondering if it's possible to selectively disable HSTS on certain apps. I host a website for a client who has a few services on subdomains that do not do TLS (I know it's bad, but I only host their corporate website), so HSTS makes them inaccessible, since the website is on the root domain.

Is it at all possible? I know it's weakening the whole "secure by default" mantra of Cloudron, but it'd be nice to see! Perhaps in a config file somewhere instead of a switch in the interface, this way you won't have droves of Cloudron users disabling it without understanding why.

Thanks in advance!

Best,

Vincent.

[girish]

@WebbleVince Do you mean you are running those domains of a self-signed certificate? And you want to disable HSTS when they are using a self-signed certificate? Cloudron's self-signed certificates should ideally have a very long validity, that way HSTS shouldn't come into picture. Maybe the bug is that our self-signed certs are not long enough?

[WebbleVince]

Hey @girish,

It's for existing subdomains, not managed by Cloudron, going to appliances that do not support TLS. Still happens in enterprise settings, even though I shudder at the idea!

Ideally, I'd like to see a switch, perhaps in an "Advanced" tab, to disable HSTS if need be; if you ever implement the "includeSubdomains" directive in the HSTS header for better security, or if browsers decide to implement HSTS differently, I'd like to be able to not kill access to systems I'm not managing on other subdomains.

I guess I jumped the gun a little opening this support thread, as Cloudron does not send the includeSubdomains directive; but it's something to consider when you host, say, a corporate website on www and the root domain, but host an appliance that does not do TLS on a subdomain. No issues as of now, really, but something to consider if you ever change the config!

Thanks!
Best,
Vincent.

[nebulon]

@WebbleVince I am not sure I get what the root issue is and how HSTS comes into play here. Can you maybe give some example description and why under which circumstances the users hit HSTS warnings in their browsers? Maybe ideally with some meta information about the certs served up from Cloudron and those other services.

[WebbleVince]

@nebulon Like I said, I thought it would be an issue for a particular client, but it's not!

However, only as long as the config stays as it is; if you ever strengthen it by adding the "includeSubdomains" directive in the HSTS header (as it is advised sometimes in some of the readings I found for better security), you could cut access to subdomains that are not managed by Cloudron and cannot do TLS.

The typical fictional scenario, if the config ever changes, would be:

• www.watering-plants-automatically.cloud is a website from a company that offers to manage clients' gardens; the designer of the website hosts it on its Cloudron instance for the client.
  The company already has stuff they host on subdomains, and won't relinquish access to the DNS server for security reasons. However www and the root domain both point to the Cloudron server IP, so Let's Encrypt works fine in "Manual" mode in the Domains & Certs tab of the designer's Cloudron;
• An end-user visits the website, decides to sign up and pay for their new fangled tool, which is hosted at myplants.watering-plants-automatically.cloud. This subdomain points to the IP of the appliance that manages the users' gardens. This is an old, crummy box that won't allow TLS, because it's almost an antic at this point;
• The user cannot connect to their tool, and throws an HSTS error.

It's not an issue yet, but it might be something to think about if you ever consider changing the configuration (let's say, if you decide all domains with a wildcard cert should have includeSubdomains in their HSTS headers).
Security-wise, it makes a ton of sense: let's say you type http://www.domain.tld in your browser.

• The server 302s you to https://www.domain.tld which has the HSTS header and "includeSubdomains"
• You later type http://mail.domain.tld in your browser: the browser will immediately connect to https instead, avoiding potential MITM attacks.

Pretty powerful, but it might be an issue in this particular case where some subdomains shouldn't be covered.

I initially thought I read in the docs that the HSTS config was such that all subdomains were included, and I remember that before using Cloudron, for this specific client, I set the header to "includeSubdomains", which promptly disallowed access to many tools I do not host because they didn't support TLS on them, if the user visited the main website before.

So yeah, feel free to close that topic, because it's not an issue unless you decide to change the config server-wide