Should HSTS Preload List affect unqualified hostnames?
Project Member Reported by firstname.lastname@example.org, Dec 12 2017
agl@, rsleevi@, thoughts on this one? In Chrome 63, we added *.dev, *.app, *.page, *.foo, and *.chrome to the HSTS preload list. Perhaps surprisingly, the dotless (“plain hostnames”) http://dev/, http://page/ http://app/ http://chrome/ and http://foo/ are all impacted by new HSTS rules as well. We probably should not apply HSTS preload rules to these unqualified hostnames to avoid breaking users' Intranet sites. However, we may want to allow individual sites on unqualified hostnames to opt-in to HSTS via the response header.
Dec 12 2017,
I feel this is working as Intended. Such intranet sites are themselves broken by virtue of ICANN's policies around delegating them in the first place. We also have in place the ICANN transition to warn users, particularly for cases like http://foo.dev Unqualified hostnames should never be able to opt-in to HSTS. As a result of ICANN's policy decisions, unqualified hostnames are effectively 'squatters', and should be considered deprecated and, as captured in SSAC policy, a security risk.
Dec 12 2017,
In order to avoid confusion, when writing HSTS names I write, say, (*.)dev and (*.)app in order to try and convey exactly what is covered. I think I agree with sleevi here that these are now global names and we shouldn't pretend otherwise.
Dec 15 2017,
(Removing the bug from the enterprise triage queue as the corresponding owners seem to be involved already.)
Dec 18 2017,
If the Enterprise team isn't screaming about us blowing up Intranets, then SGTM.
Sign in to add a comment