User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20180326230345 Steps to reproduce: I put the literal string "example.org" into the address bar, in a new browser profile. Actual results: Firefox did cleartext http over port 80 and i ended up at http://example.org Expected results: Firefox should have first tried port 443 with TLS, in which case i would have ended up at https://example.org/ Not all web sites are https-capable, and some websites that do have https will redirect the user explicitly back to http. The change i'm proposing here should not get in the way of those websites (though it may make them take a little bit longer to load). The proposal below is *only* for the case where the user has hand-entered or pasted ("manually entered") a schemaless URL -- that is, a URL-looking thing that does not explicitly specify http:// or https://. In that case: * If the connection to port 443 fails (e.g. ICMP "port closed"), or the TLS handshake fails (e.g. certificate failure), or a brief (5sec?) timeout elapses without a TCP SYN/ACK from the server ("port filtered"), * and Firefox does not have an HSTS record that covers this host, then: * Firefox should not display any of the above failures to the user, but should fall back to trying cleartext http on port 80. This is strictly better than the current behavior: * it is vulnerable to active attackers, but it protects against passive monitoring in cases where the website is https-capable. * because the user did not specify a schema, it is not disobeying a direct command from the user. * it does not introduce any new failure modes for the user to stumble into. * because it is HSTS-aware, the failover does not bypass any security directives from the website operator. * it causes http websites to be slightly slower in some contexts, providing (yet another) incentive for website operators to enable https. It introduces a bit of weird internal state -- the browser needs to *know* that the context it is in is this "manually entered" initial pageload, so that it can avoid displaying the typical failure screens if the https connection does not go through. It also introduces an interesting error-handling question: if the cleartext http connection on port 80 fails, should the browser display error messages from the port 80 connection, or from both the port 80 and port 443 connections (they may have different failure modes)? This is sort of similar to dealing with "happy eyeballs" IPv4+IPv6 connections, or with connection failures to hosts with multiple IP addresses. I think it would be fine for the first implementation to show only the errors from the port 80 connection by default, though.

Hi Daniel, First of all, please retest this on the latest stable build available (v59). I have tested this issue on the latest Firefox release build and also on other available browsers (Chrome/Opera/Safari) and the behavior is the same on all of them. And also, please take a look at this discussion related to the same topic: https://security.stackexchange.com/questions/81801/why-do-browsers-default-to-http-and-not-https-for-typed-in-urls

Based on the lack of information from the reporter this bug will have the Status: Resolved as incomplete. If you still encounter the issue, feel free to reopen the bug with more information. Thank you for your time.

Sorry, i'm not clear what you NEEDINFO from me, so i'm clearing the flag here. Feel free to ask me more details specifically if you like. To be clear from my side: yes, i agree with you that all other available browsers, including older and the most recent versions of Firefox, default to http. I'm explicitly proposing here that Firefox take the lead and default to trying https where possible. I'm asking for a change in historical behavior. I have read the referenced stackexchange post, and i know and understand the history described there. It is 2018, and browsers like Firefox which take end-user privacy seriously should be trying to use https where possible. I understand the tradeoffs in doing so, which is why i outlined a nuanced plan of action, not just failing directly for sites that do not currently support https.