Able to reproduce the issue on chrome reported version 69.0.3464.0 and on latest chrome 69.0.3466.0 using Mac 10.12.6, Ubuntu 14.04 and Windows-10. As this issue is seen from M-60(60.0.3112.0), hence considering this issue as Non-Regression and marking it as Untriaged.

Thanks!

With such a behavior one wouldn't have to re-open port 80 until a domain is HSTS preloaded. Also think of future's older devices which would otherwise just fail to connect (as seen on the screenshot). This ticket is - in the first place - only about top-level navigations.

I don't think we want to be doing this - this would potentially increase frequency of people navigating to hijackable HTTP origins when they really want an HTTPS origin, which seems to somewhat defeat the point of HTTPs.

That having been said, I'll defer to SSL and omnibox folks on this.

Adding Enamel folks.

Current situation:
This server is configured as if browsers would already default to https://.
I type in "terrax.in-berlin.de" and get ERR_CONNECTION_REFUSED. In a different case I see the same text in the address bar, but without an error. (Screenshot)
In the future, old browsers may get more often into such a situation.
As long a browser still wants to default to http:// it should have the courtesy to retry top-level navigations via https://.

If this domain would temporarily open port 80 until it is HSTS preloaded:
1. I type in "terrax.in-berlin.de" and will be insecurely redirected to https. A HSTS header is transmitted.
2. Afterwards, "terrax.in-berlin.de" or http://terrax.in-berlin.de will be upgraded within the browser.

"Try to connect via https:// if a connection is refused on port 80":
I type in "terrax.in-berlin.de" (or click on a http://terrax.in-berlin.de link on the web) and the request would be retried via https. It's just as if my top-level navigation has been insecurely redirected by the server.
(Other failing http:// requests shouldn't be retried via https, hence one should fix all URLs and/or deploy HSTS and a good CSP.)

[omnibox triage] leaving as untriaged for the security team to pick up.  We defer to them on this issue.

mmenke, can you elaborate on #4? I'm not sure I see how this would increase people navigating to HTTP origins.

If navigating to HTTP origins works, when someone really wants HTTPS, then people will learn to just do it, no?  Moreover, server operators could just pull the plug on serving resources over HTTP to get a poor-man's HSTS, which is also something I'd rather not encourage.

There are two possible levels of how this fallback/upgrade of top-level navigations in case of a connection error could be implemented:

a) Rudimentary:
http://example.com[:port]/ wouldn't be touched.
example.com[:port] would be retried via https.

b) Suggested way of doing the fallback/upgrade of top-level navigations:
http://example.com:port/ wouldn't be touched.
http://example.com/ would be retried via https.
example.com[:port] would be retried via https.

As subresources wouldn't be retried via https (to preserve incentives) this wouldn't be a poor-man's HSTS.
If someone untaught sees "http://example.com" on an old letter and manually types it in, a request wouldn't fail.
Theoretically it would also allow to move an https website to an https-only provider which will immediately request preloading then.

To have it in contrast; a potential behavior of a browser defaulting to https:
example.com[:port] would be https.
http://example.com:port/ would be http.
http://example.com/ would be http, but retried via https in case of a connection error.

Or would you prefer to always retry via https even a port is given?

A more pretty list:

Advantages
- Accessibility: Manual requests without protocol or clicks on misspelled links (http instead of https) wouldn't fail. You no longer have to open legacy port 80 until all domains are finally preloaded. Otherwise there will a problem of understandability if protocols are hidden by default (Screenshot).
- Compability & Deprecation: Old browsers don't get updated HSTS preload lists. Server operators wouldn't have to open legacy port 80 for new projects in the future.
- Privacy: Path and query of a misspelled link (http instead of https) or of a manually entered URL without protocol wouldn't be revealed to passive interception if a domain isn't preloaded (yet). Regular HSTS could kick in. (I don't know if you're supporting TCP Fast Open for http:// and if it could sabotage this.)

Potential Risks
- Owners of https-only websites might discriminate users of other browsers than Chrome and Firefox if they manually enter a domain as long as it's still pending preloading. I'd expect that Edge and Safari are interested in a more user-friendly error handling. Search engine users will definitely find their way.

Ensured
- As only top-level navigations would be retried via https one still would have to fix wrong URLs and/or to set a CSP with upgrade-insecure-requests.
- hstspreload.org supports https-only websites since December 2016.

Clarification: I'm not a Firefox Dev, but you can see that they would want something like this.

I would assign this to estark@, because she was triaging it on behalf of the security team.  Her questions from comment #9 were answered.  But she is out now, so I'm giving it to cthomp@ to further triage/evaluate the suggestion.

Sorry, my status is a bit of a lie, I'm not completely out quite yet, though I'm curious to hear cthomp's thoughts on this anyway.

My guess is that servers that don't respond on port 80 are sufficiently rare that this won't really change user behavior. Plus, I don't think we really want to require users to type "https://" when they navigate (rather, we should try to make it so they don't have to type https://), so I'm not too worried about doing something that might untrain them from typing https.

I'd be fine with leaving this open as a low-priority feature request, but I don't feel strongly about it. It seems to me like it would be a pretty rare edge case.

I generally like this idea, but I wonder how prevalent this setup is among sites. I might be able to crunch some of my existing HTTPS Status data for, say, the Top 1M sites to try to get some perspective on that.

Re #10: Is this that different from HTTP->HTTPS server redirects? I imagine this will have similar or worse latency as serving a 301/302 redirect, which may still give incentive for site operators to switch to HSTS.

This doesn't necessarily mean that we want to allow for this additional exception (and the complexity it entails), especially since it seems likely to be "by accident" on the part of the operator more often than an explicit 30X redirect would be. Sites in an "accidentally working" state seem like they'd be much less likely to fix it (by either adding the explicit redirect or enabling HSTS) than if they were "kind of broken" and users would report it to them.

I agree with #16 that we don't really want users to have to care about typing "http" vs. "https" when they do a typed navigation. Most of the time they already don't think about that (with the omnibox). For link navigations, the user already is not typing the scheme.

Networks are also unfortunately kind of flaky. I'm not sure we can reliably distinguish a service not existing over :80 vs the network just failing. Error codes also vary a lot when things like sockets are involved.

Today if you get a network error fetching a resource, the user can reload, and we have an autoreload feature in the error pages there. Any feature here will likely interact with that flow funny, so we'll want to take some care there.

> Error codes also vary a lot when things like sockets are involved.

Sorry, that should have been "when things like proxies are involved."

Could also end up in a new sort of fun redirect loop, too:

http fails, so we try HTTPS.  HTTPS redirects to http.  HTTP fails, so we try HTTPS.  While our redirect code would detect this (If the upgrade logic is in NavigationURLLoader, at least), failing in that case with a redirect loop error seems confusing.