New issue
Advanced search Search tips
Starred by 4 users
Status: WontFix
Owner: ----
Closed: Dec 18
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Bug



Sign in to add a comment
Should HSTS Preload List affect unqualified hostnames?
Project Member Reported by elawre...@chromium.org, Dec 12 Back to list
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.
 
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.

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.
Labels: Enterprise-Triaged
(Removing the bug from the enterprise triage queue as the corresponding owners seem to be involved already.)
Status: WontFix
If the Enterprise team isn't screaming about us blowing up Intranets, then SGTM.
Sign in to add a comment