Note, two of us on the corporate VPN see this same issue - but only with the Beta build. 

chrome://net-internals/#dns reports the correct IP. 

It is able to visit to the IP directly. 

Difference: IP visit directly does NOT redirect to HTTPS...

Try http:// - redirects to https:// automatically...fails b/c there is no HTTPS. This is an internal opendns.com subdomain and does NOT have an HTTPS version. 

Canary/Stable, no redirect to HTTPS happens. Works just fine. 

Issue: Do not redirect all to HTTPS if not requested. 

Note, this may also be a fault of HSTS for opendns.com given:

Strict-Transport-Security: max-age=31536000; includeSubDomains


But prior builds were not impacted negatively by this being set. 

Repro update: Should be able to repro for an http-only website subdomain which advertises HSTS includeSubDomains when it in reality has no HTTPS support for all subdomains. 

I defer to the HSTS folds, but I believe it's expected that advertising HSTS when not actually supporting HTTPS will break you.

> I defer to the HSTS folds, but I believe it's expected that advertising HSTS when not actually supporting HTTPS will break you.

Indeed, that's one of the main security features of HSTS.

alexander@, could you confirm that deleting `opendns.com` (and any intermediate domains, if they exist and serve an HSTS header that the client might have observed)) at chrome://net-internals/#hsts allows accessing the subdomain until you visit https://opendns.com again?

Oops, that should be "HSTS owners" (Don't ask me where "folds" came from)

Can confirm, deleting the HSTS entry manually from chrome://net-internals/#hsts *does* work to clear the issue entirely. Visiting the opendns.com homepage once more re-loads HSTS and poof, the issue is back. 

It's definitely a delta in behavior between versions (canary continues to work just fine as does stable) - although I don't necessarily disagree that it is not "as expected" but does place a lot of burden on the end user. 

In the event Chrome is being expected to behave this way to enforce the stated HSTS (i.e. begin enforcing) - I would need to consult the HSTS declaration to adjust subdomains accordingly to avoid torpedoing our internal sites. 

Thank you for providing more feedback. Adding requester "lgarron@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

> It's definitely a delta in behavior between versions (canary continues to work just fine as does stable)

That sounds very unlikely – the implementation of HSTS hasn't substantially changed in years.
I suspect that visiting https://opendns.com in Canary/Stable will cause the relevant subdomains to fail to load in those profiles, too. Let me know if that's not the case, and we can reopen the bug.

> In the event Chrome is being expected to behave this way to enforce the stated HSTS (i.e. begin enforcing) - I would need to consult the HSTS declaration to adjust subdomains accordingly to avoid torpedoing our internal sites.

Yes, it sounds like `includeSubDomains` is not right for your case. You can remove the directive and get people to visit https://opendns.com in order to clear the old setting.

Can confirm that stable/canary behavior does differ and I am not able to reproduce the issue in either. However, the suspected cause - as you're saying - was not correct. The HSTS is behaving as it should there with the all subdomains selected. 

The delta appears to be that I can't get canary/stable to load that HSTS no matter how many times I visit opendns.com. HSTS doesn't appear. Beta - it appears, but not every time. 

Every time opendns.com appears in the HSTS chrome://net-internals/#hsts section, the subdomains fail. That part, not a bug, working as intended. 

Chrome seems to be inconsistent in actually adding the HSTS data to the browser, and it didn't actually get around to doing it at all until the current beta release. Never once saw it. No matter how many times I visit opendns.com in canary, for example, can't get the HSTS to appear. Beta - it appears sometimes. This part is reproducible by visiting opendns.com after clearing the HSTS storage. Sometimes it comes back, sometimes not. I can't get it to appear in stable or canary. 

In summary, while yes, it is correct that we should adjust opendns.com's HSTS declaration to avoid affecting other subdomains not in HTTPS -  Chrome's behavior has changed to actually load that HSTS to enforce. Reproducible by checking HSTS storage for stable vs beta vs canary after visiting opendns.com. 

Edit: Please close, you folks are correct - this is not a Chrome issue. I'm not sure what's triggering this to change now - I will verify with the website team as we may have also changed HSTS behavior about the time the new beta got released. 

Canary/stable didn't reproduce since visiting opendns.com was long done - so Canary/Stable couldn't reproduce without more exacting steps - visiting a new location like opendns.com/random produced the HSTS entry + reproduced in every build of chrome.