Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should the includeSubDomains setting default to false? #7

Open
frdrks opened this issue Feb 14, 2018 · 2 comments
Open

Should the includeSubDomains setting default to false? #7

frdrks opened this issue Feb 14, 2018 · 2 comments

Comments

@frdrks
Copy link

frdrks commented Feb 14, 2018

Hi!

I encountered a sneaky issue today, due to theincludeSubDomain setting. I have set up a simple page, where I used your yes-https package. It mostly works like a charm, but this page is served on both a "www" subdomain and on the root domain – causing the HSTS policy to be enforced on absolutely all my subdomains. This is all fine and dandy if everything points to your apps and services, where you have set up TLS/HTTPS. On the other hand, if some of these are forwarding or redirecting to your mail provider etc. – things get more interesting.

So my question/suggestion is: Should the includeSubDomain setting default to false? This issue might be caused by a suboptimal setup of my web app and domain. But I suspect this is not an uncommon scenario around the web. And I had to use quite a few brain cycles to find the culprit. So in my mind it make more sense to explicitly ask to enforce the HSTS policy on all sub domains.

Any thoughts?

@JustinBeckwith
Copy link
Owner

Apologies for any trouble this may have caused. I'd generally prefer to keep the "more secure by default" approach we have here now. Generally, I'd expect more users to want coverage over their own domain and subdomains rather than a limited scope. It's entirely possible I'm wrong :) I'd rather someone get tripped up during initial configuration by being too secure, rather than being lax by default and having someone find out they weren't protected.

Does this make sense?

@frdrks
Copy link
Author

frdrks commented Feb 15, 2018

No worries :) Had I read the documentation, I would have picked up on this. In the end I learned more about HSTS – which is a good thing.

This makes sense, and in most cases I would agree that the "secure by default" approach is preferred. In this case, I would argue that an explicit approach may be favorable. By defaulting to to including all the subdomains, we make an assumption that all domains/subdomains are handled by the respective web app. Doing so, I feel that we are giving more responsibility to the app than it I should have. And if all subdomains aren't set up and configured for https, you will experience strange side effects – which are not very obvious, and hard to debug.

What I'm getting at, is that the web app shouldn't enforce settings for subdomains not served by itself. Especially when this setting comes with requirements/dependencies that needs to be met, and aren't provide by the yes-https package.

Anyways, this is mostly nitpicking – and it also possible that I'm wrong :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants