Closed Bug 1934452 Opened 2 months ago Closed 2 months ago

Firefox won't connect to non-https

Categories

(Core :: Networking, defect)

Firefox 133
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mah042, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:133.0) Gecko/20100101 Firefox/133.0

Steps to reproduce:

M4 Mac mini (new)
MacOS 15.1.1
Firefox 133.0 (aarch64) (fresh install, new profile, all defaults, no extensions. "HTTPS-Only Mode" disabled by default)
Entered local website http://192.168.1.211 in the address bar and hit ENTER

Actual results:

Address bar automagically changed to https://192.168.1.211 and ffox displayed:

Unable to connect

An error occurred during a connection to 192.168.1.211.

The site could be temporarily unavailable or too busy. Try again in a few moments.
If you are unable to load any pages, check your computer’s network connection.
If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the web.

Browser console shows:
GET http://192.168.1.211/ NS_ERROR_CONNECTION_REFUSED
GET https://192.168.1.211/ NS_ERROR_CONNECTION_REFUSED

https failing is not unexpected as that website does not provide https

If I enter that exact URL, http://192.168.1.211, into Safari on the same machine, it succeeds (i.e. non-https)

ffox 133.0 on a Win10 machine on the same network succeeds.

Expected results:

ffox should have connected to the available, local website http://192.168.1.211

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

I uninstalled ffox from my mac.
Removed all folders & files under ~/Library with "Mozilla" or "Firefox" in the name.
Rebooted
Downloaded and installed ffox 133.0 from https://www.mozilla.org/en-US/firefox/new/
Started up fresh new ffox with fresh new profile using all the defaults
Typed in 192.168.1.211 into the address bar and hit ENTER
It automatically changed it to https://192.168.1.211 and FAILED to connect
I deleted the 's' from 'https' in the address bar, hit ENTER and voila... it succeeded connecting to http://192.168.1.211.
Now when I type in 192.168.1.211 and hit ENTER it DOES NOT automatically go to https://192.168.1.211, but happily continues to http://192.168.1.211 and succeeds.
It would seem I've resolved the issue. ¯_(ツ)_/¯

Thanks for the update. I'll close this bug, since it works for you.
This seems to be caused by bug 1812192.

Status: UNCONFIRMED → RESOLVED
Closed: 2 months ago
Resolution: --- → WORKSFORME
See Also: → 1812192

(In reply to Mark Horstman)

Glad to hear this is no longer a problem for you. Still, the behavior you described is confusing me a bit. In the configuration you described, only entering a URL without a scheme (http://) should trigger an "upgrade" to https. Your initial comment said "Entered local website http://192.168.1.211 in the address bar and hit ENTER", but you later also say "Typed in 192.168.1.211 into the address bar and hit ENTER". Did you originally really include the scheme, and got the same behavior? And even if Firefox is upgrading a load, it should be downgraded again if an error like NS_ERROR_CONNECTION_REFUSED is encountered.

Browser console shows:
GET http://192.168.1.211/ NS_ERROR_CONNECTION_REFUSED
GET https://192.168.1.211/ NS_ERROR_CONNECTION_REFUSED

This sounds strange, and would suggest that the site is available neither through HTTPS and HTTP, which would explain why no successful downgrade was possible. This does not match the fact though that you are able to connect to it just fine through Safari (and even Firefox on another PC).

I am just speculating now, but what I imagine could have happened is that the initial HTTPS connection somehow crashed the server for a short time. This then prevented the downgraded load from succeeding, meaning it got fixed up to HTTPS again and then completely failed. For a more useful analysis, I would need more information on the server that you are trying to connect to. Are you able to shed some light on the kind of software that is running on it?

I deleted the 's' from 'https' in the address bar, hit ENTER and voila... it succeeded connecting to http://192.168.1.211.
Now when I type in 192.168.1.211 and hit ENTER it DOES NOT automatically go to https://192.168.1.211, but happily continues to http://192.168.1.211 and succeeds.
It would seem I've resolved the issue. ¯_(ツ)_/¯

This sounds expected again, and is what we implemented recently in Bug 1919544. Glad to hear that it was actually useful for working around the problem here.

See Also: → 1919544
Flags: needinfo?(mah042)

(In reply to Malte Jürgens [:maltejur] from comment #4)

I deleted the 's' from 'https' in the address bar, hit ENTER and voila... it succeeded connecting to http://192.168.1.211.
Now when I type in 192.168.1.211 and hit ENTER it DOES NOT automatically go to https://192.168.1.211, but happily continues to http://192.168.1.211 and succeeds.
It would seem I've resolved the issue. ¯_(ツ)_/¯

This sounds expected again, and is what we implemented recently in Bug 1919544. Glad to hear that it was actually useful for working around the problem here.

Correction: Bug 1919544 only landed in Firefox 134, and the report only talks about 133, so it seems unrelated after all.

EDIT: Since Nov 19, there has been a gradual rollout of HTTPS-First (a feature that tries to upgrade all navigation in the browser, with a fallback to HTTP) for 1% of Firefox release users. In your original profile, you probably got enrolled in HTTPS-First. That would explain why a new profile would have behaved differently, even in 133. With HTTPS-First generally disabled, Firefox still performs "upgrades" in the address bar, but crucially only when the scheme is missing. And once you load the site through http once, that will be saved in your navigation history. So on subsequent loads, the address bar will just recommend the history entry, which will not be upgraded in that configuration. HTTPS-First on the other hand, prior to Bug 1919544 in 134, always tried to upgrade address bar loads, regardless of their scheme. You can test this by force-enrolling this rollout again by visiting about:studies?optin_slug=https-first-in-release&optin_branch=httpsfirstenabled, then you should get the behavior from your original comment again.

See Also: 1919544

(In reply to Malte Jürgens [:maltejur] from comment #4)

(In reply to Mark Horstman)

Glad to hear this is no longer a problem for you. Still, the behavior you described is confusing me a bit. In the configuration you described, only entering a URL without a scheme (http://) should trigger an "upgrade" to https. Your initial comment said "Entered local website http://192.168.1.211 in the address bar and hit ENTER", but you later also say "Typed in 192.168.1.211 into the address bar and hit ENTER". Did you originally really include the scheme, and got the same behavior? And even if Firefox is upgrading a load, it should be downgraded again if an error like NS_ERROR_CONNECTION_REFUSED is encountered.

Browser console shows:
GET http://192.168.1.211/ NS_ERROR_CONNECTION_REFUSED
GET https://192.168.1.211/ NS_ERROR_CONNECTION_REFUSED

This sounds strange, and would suggest that the site is available neither through HTTPS and HTTP, which would explain why no successful downgrade was possible. This does not match the fact though that you are able to connect to it just fine through Safari (and even Firefox on another PC).

I am just speculating now, but what I imagine could have happened is that the initial HTTPS connection somehow crashed the server for a short time. This then prevented the downgraded load from succeeding, meaning it got fixed up to HTTPS again and then completely failed. For a more useful analysis, I would need more information on the server that you are trying to connect to. Are you able to shed some light on the kind of software that is running on it?

The initial failure (before uninstalling and clearing all Mozilla/Firefox files and folders) I entered http://192.168.1.211 and it immediately changed to https: and failed. The browser console showed it had attempted and failed http, then https. The webserver was there (pi-hole) as I confirmed via Safari (on the same mac) and ffox on a Win10 box on the same network. I also checked the pi-hole webserver logs and there were no indications of any anomaly.

Later after uninstalling and clearing all Mozilla/Firefox files and folders my first attempt was just a bare 192.168.1.211.

Was the change to "HTTPS-first" communicated? I certainly missed it. That would've been Good To Know. But that doesn't explain the initial http failures. That's a head-scratcher.

I deleted the 's' from 'https' in the address bar, hit ENTER and voila... it succeeded connecting to http://192.168.1.211.
Now when I type in 192.168.1.211 and hit ENTER it DOES NOT automatically go to https://192.168.1.211, but happily continues to http://192.168.1.211 and succeeds.
It would seem I've resolved the issue. ¯_(ツ)_/¯

This sounds expected again, and is what we implemented recently in Bug 1919544. Glad to hear that it was actually useful for working around the problem here.

Flags: needinfo?(mah042)

(In reply to Mark Horstman from comment #6)

The webserver was there (pi-hole) as I confirmed via Safari (on the same mac) and ffox on a Win10 box on the same network. I also checked the pi-hole webserver logs and there were no indications of any anomaly.

Thanks for the info about the software you are running. I tried setting up a pi-hole on my local network to reproduce this, but for me everything worked just fine, and I was able to connect to it via HTTP without problems. Additionally, from a quick web search, I didn't find any other people having similar looking issues connecting to pi-hole, both generally and with Firefox specifically.

The initial failure (before uninstalling and clearing all Mozilla/Firefox files and folders) I entered http://192.168.1.211 and it immediately changed to https: and failed. The browser console showed it had attempted and failed http, then https. The webserver was there (pi-hole) as I confirmed via Safari (on the same mac) and ffox on a Win10 box on the same network. I also checked the pi-hole webserver logs and there were no indications of any anomaly.

Okay, thanks for the confirmation. This behavior sounds more and more like it doesn't have anything to do with HTTPS-First, or the upgrades we do in the address bar alone. If any HTTPS-First upgrade had happened, we shouldn't see a failed http connection first. And additionally, the HTTPS-First and address bar upgrades shouldn't even happen on local (192.168.0.0/24) ip addresses, as they are explicitly exempted in the code.

I know that the issue is already fixed for you, but if you are still interested and have the time, the following would be interesting to know to confirm wether this has anything to do with HTTPS-First:

  1. When repeating your steps in a fresh profile, and then vistiting the top-right menu > More tools > Browser console > Multiprocess, can you find any logs containing "HTTPS-First"? You can search with Ctrl+F in that window. And for a fresh profile, you just need to visit about:profiles to create a temporary new profile. You don't need to uninstall Firefox completely.
  2. Does flipping dom.security.https_first to true in a fresh profile in about:config take you back to the old behavior where not even removing the "s" from the scheme fix anything?

Was the change to "HTTPS-first" communicated? I certainly missed it. That would've been Good To Know. But that doesn't explain the initial http failures. That's a head-scratcher.

For this particular 1% rollout, I don't think there was any public communication yet. That is because HTTPS-First was designed to, in theory, not cause any user-noticable changes, beside more sites loading over HTTPS if they support it, and sites that don't support HTTPS loading slightly longer. And because this was only a 1% rollout. Once HTTPS-First will be released for all users, it will of course be announced. Additionally, this was already enabled in private browsing for some time, you can read about that here: https://blog.mozilla.org/security/2021/08/10/firefox-91-introduces-https-by-default-in-private-browsing.

I'll mess around a bit and see if I can reproduce.

One of the details I neglected to mention was the steps I normally follow when setting up a new ffox profile, which I performed as usual on the initial mac setup:

about:config changes
browser.tabs.closeWindowWithLastTab : false
extensions.pocket.enabled : false
browser.search.openintab : true
browser.sessionstore.resume_from_crash : false
network.IDN_show_punycode : true
extensions.htmlaboutaddons.recommendations.enabled : false

Extensions:
https://addons.mozilla.org/en-US/firefox/addon/consent-o-matic/
https://addons.mozilla.org/en-US/firefox/addon/clearurls/
https://addons.mozilla.org/en-US/firefox/addon/duckduckgo-for-firefox/
https://addons.mozilla.org/en-US/firefox/addon/facebook-container/
https://addons.mozilla.org/en-US/firefox/addon/multi-account-containers/
https://addons.mozilla.org/en-US/firefox/addon/privacy-badger17/
https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/
https://addons.mozilla.org/en-US/firefox/addon/video-downloadhelper/
https://addons.mozilla.org/en-US/firefox/addon/nuke-anything-enhanced/ (disabled)

ffox sync:
Bookmarks
Passwords
Add-ons
Settings

All my other ffox desktops are Win10 Pro 64 machines.

After the failure of this initial ffox setup on my mac, I scraped all traces of ffox off the mac, re-installed and started a fresh, default profile without performing the about:config changes, no Setting changes, no extensions or signing in to ffox sync. When that succeeded in "getting around" the failure, I went ahead and did the about:config changes, my normal Settings modifications and manually added my usual extensions. But before turning on syncing, I logged into another machine and modified ffox syncing to turn off syncing Add-ons and Settings. Now I just ffox sync Bookmarks and Passwords. Afterwards the failure behavior was still gone. So the only difference between the profile that failed and this profile that doesn't is I'm no longer ffox syncing Add-ons and Settings. It may mean nothing, but you never know.

I'll perform the additional testing you request. I too would like to know what's going on.

Since you are on a Mac, let me just mention this here: https://bugzilla.mozilla.org/show_bug.cgi?id=1935845#c5

Just in case, please check if your Firefox has the permission to find and communicate with devices on the local network under "System Settings" > > "Privacy & Security" > "Local Network". Otherwise you get blocked by the OS.

See Also: → 1935845
You need to log in before you can comment on or make changes to this bug.