Open Bug 1767588 Opened 2 years ago Updated 5 months ago

option to disable automatic https for local ip such as localhost, router logins (192.168.0.0/16) etc.

Categories

(Core :: DOM: Navigation, enhancement)

Product:
Core
Component:
DOM: Navigation
Version:
Firefox 99
Type:
enhancement

Tracking

()

People

(Reporter: barnaclenshade, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:99.0) Gecko/20100101 Firefox/99.0

Steps to reproduce:

  1. I had disconnected from my router.
  2. I navigated to 192.168.0.1
  3. I reload the page using ctrl+R

Actual results:

  1. Firefox tried to connect via http then via https
  2. I reconnected to the router.
  3. Now also reloading wont connect until I made it http in the navigation bar

Expected results:

  1. The browser try to connect via http
  2. If network disconnected do not upgrade to https

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Networking
Product: Firefox → Core
Component: Networking → Address Bar
Product: Core → Firefox

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0

Hi,

Thank you for opening this enhancement. I will set this as New and waiting for the developer's opinion about it.

Thanks for your report.

Status: UNCONFIRMED → NEW
Ever confirmed: true

do you see autofill happening in the urlbar (part of the ip gets completed by firefox)?
what happens if you remove the https entry from history?

Flags: needinfo?(barnaclenshade)

No the autofill does not occur. I have tried to remove history, opened in private window and write http explicitly yet the same experience.
First tries to load over http and fails and then automatically tries to load over https. This action may be desirable but not when internet is disconnected or when I write it explicitly.

Flags: needinfo?(barnaclenshade)

Comment 4 seems to be related to https first in private browsing mode.

Component: Address Bar → DOM: Security
Product: Firefox → Core

I'm sorry this has taken so long to get to our team. But I'm a bit confused because your symptoms don't seem to match what I'd expect to happen from either https-only or https-first modes.

"HTTPS Only" is an option in preferences (at the bottom of the privacy and scurity pane). In this off-by-default mode you should get an error page when you go to the non-connecting https:// version of a site, and the explicit option to disable upgrades for that "domain" on that error page and via the permission icon in the address bar. Your symptoms don't sound like this.

"HTTPS First" will first try an https: connection, but if there's an explicit cert or connection failure or if it doesn't get an answer in a short timeout (3 seconds maybe?) it will revert back to using http: as originally requested. Since your actual results step 3 says it won't connect that doesn't sound at all like HTTPS First. Also, HTTPS First is only enabled in private browsing, and your comment 4 says you additionally tried a private window which implies most of the time you don't use a private window. There's silent "always in private browsing" if you disable saving history, but since you talk about having history to remove I'll assume that's not the issue either.

You removed history, but did you remove the cache? Site redirects (such as http: to https:) would be saved in the cache, though if you don't actually have a server at the https port then I don't know why the router would issue a redirect. There's also the Strict-Transportation-Security header that will remember to always use https: for a certain site, but that can't be set by a site unless you connect to it once over https:. You'd have to "forget about this site" to get rid of that setting.

In addition to all of the above, https-only and https-first ALREADY don't upgrade localhost or local IP addresses. There's a hidden pref where people can turn on upgrading local IP addresses but it's off by default
https://searchfox.org/mozilla-central/rev/1865e9fba4166ab2aa6c9d539913115723d9cc53/modules/libpref/init/StaticPrefList.yaml#3655-3659

And we NEVER upgrade localhost to https
https://searchfox.org/mozilla-central/rev/1865e9fba4166ab2aa6c9d539913115723d9cc53/dom/security/nsHTTPSOnlyUtils.cpp#747-771

Something else is going on.

Is this still happening? It might be a security addon like "HTTPS Everywhere", though presumably you would have thought of that since that's the whole point of installing that one. It might also be a security proxy doing it, perhaps installed with an anti-virus product? If you're a protonmail user you might be more likely than the average person to have other security and privacy products installed.

Flags: needinfo?(barnaclenshade)

Hey
I completely understand what you are trying to say and the point you are trying to make. But the stated point does not seem to address my concern.
This happens on a brand new installation of Firefox on a new installation of Ubuntu without any extensions or add-ons or user-scripts.

Basically if you look at the steps to reproduce, you see the first step is to disconnect from the internet and then try to navigate to the router url which makes it impossible for the router to issue redirects and makes its unlikely for any storage/redirects/cache to have a cause because its a brand new installation.

The main thing which I seem to identify is that Firefox attempts to connect via http initially which does not happen (internet is disconnected :duh) so it attempts to connect via https again and changes the url in the address bar.
Now when I connect to internet and then press refresh or CTRL + R then it attempts to connect via https only which is not what i had initially attempted to do.

I hope it is now clear what is happening and what is expected behavior.

Flags: needinfo?(barnaclenshade)

Firefox falbacks from http to https when the connection is refused.
https://searchfox.org/mozilla-central/rev/ecb14e26e11a8edd3e7110f38b3803969db618ec/docshell/base/nsDocShell.cpp#6202
Bug 1002724 introduced this behavior.

Could you still reproduce the bug when you flip browser.fixup.fallback-to-https to false from about:config?

Flags: needinfo?(barnaclenshade)
  1. I navigated to 192.168.0.1

Did you navigate to raw "192.168.0.1", or to explicit "http://192.168.0.1"? Masatoshi is talking about the "fix-up" case that only applies if you don't supply an explicit scheme. If one doesn't work at all it can't hurt to try another! I suppose they could carve out an exception for local IP addresses, but it's not true that machines at those addresses don't have certificates. All 3 routers at my house have built-in self-signed certificates, and if I set certificate exceptions for them then I do get the benefit of local TLS protecting my connections from snoopy "Internet of Things" devices.

This bug was moved to the "DOM: Security" component because it was thought that the trouble was with Firefox's intentional override of "http:" into "https:" through either the HTTP-first or HTTP-only feature, but those feature explicitly exclude local IP addresses. If no connection is working at all I'm not sure whether it's wrong to try https: as a last resord in the fix-up code, but that will be for that team to decide.

Component: DOM: Security → DOM: Navigation

(In reply to Daniel Veditz [:dveditz] from comment #9)

Did you navigate to raw "192.168.0.1", or to explicit "http://192.168.0.1"? Masatoshi is talking about the "fix-up" case that only applies if you don't supply an explicit scheme. If one doesn't work at all it can't hurt to try another!

If I read the code correctly, this "fixup" works regardless of the explicit scheme input because it triggers after the connection failure and it takes the url from the channel.

I suppose they could carve out an exception for local IP addresses, but it's not true that machines at those addresses don't have certificates. All 3 routers at my house have built-in self-signed certificates, and if I set certificate exceptions for them then I do get the benefit of local TLS protecting my connections from snoopy "Internet of Things" devices.

Did you read the comment saying "1. I had disconnected from my router"?

Redirect a needinfo that is pending on an inactive user to the triage owner.
:edgar, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(barnaclenshade) → needinfo?(echen)

(In reply to Masatoshi Kimura [:emk] from comment #8)

Firefox falbacks from http to https when the connection is refused.
https://searchfox.org/mozilla-central/rev/ecb14e26e11a8edd3e7110f38b3803969db618ec/docshell/base/nsDocShell.cpp#6202
Bug 1002724 introduced this behavior.

Could you still reproduce the bug when you flip browser.fixup.fallback-to-https to false from about:config?

I could reproduce this behavior. And after fliping browser.fixup.fallback-to-https to false, it doesn't fallback from http to https.

Flags: needinfo?(echen)
See Also: → 1002724
You need to log in before you can comment on or make changes to this bug.