New issue
Advanced search Search tips

Issue 794202 link

Starred by 4 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Dec 2017
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, Dec 12 2017

Issue description

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

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.

Comment 2 by, 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.

Comment 3 by, Dec 15 2017

Labels: Enterprise-Triaged
(Removing the bug from the enterprise triage queue as the corresponding owners seem to be involved already.)
Status: WontFix (was: Untriaged)
If the Enterprise team isn't screaming about us blowing up Intranets, then SGTM.

Sign in to add a comment