Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Enable HSTS preload for this site and all subdomains problem

    Unsolved Discuss
    3
    1 Votes
    3 Posts
    334 Views
    girishG

    Have you seen https://docs.cloudron.io/apps/#hsts-preload ?

  • Selectively disable HSTS?

    Support
    5
    0 Votes
    5 Posts
    644 Views
    W

    @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 🙂