Blacklist HSTS for localhost
Reported by
pcdev...@gmail.com,
Apr 29 2016
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36 Example URL: http://localhost with HSTS in the set Steps to reproduce the problem: 1. Run a site on localhost with HSTS header in (say like when you're developing in VS or similar) 2. Try to access other resources running on other ports of localhost 3. Fail miserably and have to resort to going into chrome://net-internals/#hsts to clear localhost out What is the expected behavior? Localhost should never be eligible for hsts it makes no sense. What went wrong? chrome treated localhost like every other domain rather than the special snowflake that it is. Did this work before? N/A Chrome version: 49.0.2623.112 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 21.0 r0
,
Apr 29 2016
Such a restriction could make it harder to test HSTS behavior before deployment. Somewhat similar to https://bugs.chromium.org/p/chromium/issues/detail?id=456712. Presumably, if we took this change we'd want other persistent declarations (HPKP) to be similarly restricted.
,
Apr 29 2016
http://localhost (e.g. without the s) won't set up HSTS. https://localhost (with the s) indicates you've already got a cert for localhost. We don't do HPKP for localhost already, because it requires a cert trusted from a public trust anchor, and those aren't allowed for localhost. Same with Expect-CT. I'm inclined to WontFix.
,
Apr 29 2016
If I test a site with HSTS on, on https://localhost:9389 then try to view a local tool such as ElasticSearchHead on http://localhost:9400 chrome will redirect to https://localhost:9400 (which obviously wont work) Theres zero messaging as the URL quickly changes. I've no issues with it being honoured but it should be checked and upgraded on localhost per-request at the very least. For a non-public reserved hostname the user should never have to crawl through the bowels of chromes configuration to removed a 'cached' entry.
,
Apr 29 2016
I also offer up a basic twitter search https://twitter.com/search?q=hsts%20localhost&src=typd It's a pretty common annoyance.
,
Apr 29 2016
Disagree on the "non-public reserved hostname" being exempted from HSTS. It's entirely valid to do so, and can benefit users' security. I have no idea what you mean by "checked and upgraded on localhost per-request", since HSTS is spec'd explicitly to apply to all ports, and to persist. Have you tried simply not setting HSTS? Is there some application you're using that's doing that? If it's not what you want, you should ideally file the bug there, rather than suggesting browsers (Chrome, Firefox, IE, Safari) all add exceptions. It's generally simpler to fix the thing sending HSTS.
,
May 2 2016
,
Feb 18 2017
,
Feb 19 2018
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by jkarlin@chromium.org
, Apr 29 2016