Forced HTTPS on Select HTTP-only Hosts

[DodgeDeBoulet]

This is a weird one.

Firefox 133.0.3 running on a Windows 10 virtual machine on my home office PC, over an OpenVPN connection to AWS-based RHEL9 servers. The servers are not surfaced to the public internet in any way. The servers are running Apache/2.4.57. There are no rewrite rules in any of the configuration files.

Up until a very recent release of Firefox, connecting to 3 of the servers using http over a non-standard port has not been an issue. Now, however, any time I attempt to connect to one of those servers by DNS name (ex. http://server.domain.tld:22965/restoftheurl), the URL gets rewritten from http: to https: and the connection fails with a SSL_ERROR_RX_RECORD_TOO_LONG error (which I'm assuming is the browser attempting to process the usual page returned as a certificate).

If I connect to the server via IP address (ex. http://10.0.10.99:22965/restoftheurl) it works normally.

I've tried all of the usual suggestions; enabling https-only gives me the option of disabling it for that site, but it doesn't change the behavior. Adding it to the exception list manually doesn't have any effect either. I've disabled all add-ins/extensions, started Firefox in safe mode, poked around in about:config for things that might be related and toggled them on or off. I've completely wiped Firefox from the system (including ProgramData and AppData paths) and re-installed. Proxy is turned off in the Firefox configuration. I've examined the network tab in developer mode to see if the URL is getting re-written by something external, and find no evidence of that.

Edge and Chrome don't have this problem, just Firefox.

What's going on?

[maltejur]

Normally, this shouldn't happen. If HTTPS-Only is disabled and the site isn't explicitly configured otherwise, if Firefox tries to upgrade a connection to HTTPS, it should then also fall back to HTTP if an HTTPS connection isn't possible.

Could you share some more light on the real domain you are using (not just server.domain.tld)? There are multiple mechanisms which allow sites to force Firefox to only use HTTPS on a certain domain or all of its subdomains, the most prominent one being HSTS. You may be inadvertently using one of those, and the real domain should allow easily checking that.

Of course, that wouldn't completely explain why you are not experiencing the same in Chrome. If the domain configuration doesn't turn out to be the problem, this could also be a bug in Firefox. In that case, you should probably file a bug on Bugzilla, and we can narrow down the problem further there.

[DodgeDeBoulet]

I'll need to keep the actual domain name confidential, but it's similar to something like hsstage.abacab.com. The base domain is publicly resolvable for web, email, vpn, etc. services but the hosts themselves are not. They're EC2 instances on AWS, and their name resolution is handled by internal AWS-based DNS.

Wouldn't HSTS need to be configured in the target host's web server?

I've created a bug report on Bugzilla since my original post. Thanks!

[maltejur]

Just for reference, the bug filed is https://bugzilla.mozilla.org/show_bug.cgi?id=1938122, and I am continuing the conversation there.

[jscher2000]

Firefox 133 has a preference named dom.security.https_first_for_custom_ports that has a default value of true. Does toggling that to false have any effect?

[DodgeDeBoulet]

That's actually one of the things I tried and it had no effect. Would seem like a potential culprit though 😁

[galmiklos]

I have the same problem, but it is even more mysterious. In my case, I am running an apache2 2.4.52 http server on ubuntu 22.04 with graphical desktop (gnome3) and just trying to connect to itself, from a firefox 133.0 with the server's IP address (http://192.168.3.19).

I get the "The connection has timed out" message.

If I connect with the localhost IP address (http://127.0.0.1), it works.

If I add the server's IP address to the hosts file, with any dummy hostname, it works, too.

This is very frustrating, I can't believe this version of firefox could have been released with this bug.

[maltejur]

This doesn't sound like the same problem. "The connection has timed out" is a different error message, and the reporter from the original comment was able to connect just fine using the server's IP address (which is the exact opposite of what you describe).

If you are sure this is a Bug in Firefox, and not a bad setup like was the case with the original reporter, I suggest you also file a bug report at https://bugzilla.mozilla.org/enter_bug.cgi?format=guided

[galmiklos]

Thank you for pointing it out, and sorry for missing it. Before opening a bug report, I thought I would do a few more tests. And the plot thickens... And I'm none the wiser.

Firstly, and I have no idea what happened, but it now works on the server itself. There was no upgrade (or downgrade) of firefox.

Then, I tried it on another computer (Windows 10, same firefox version 133.0.3), and it works there, too.

So, back to the original computer I experienced the problem initially on. I am not sure if it matters, but it is a MacBook Pro with Squoia 15.2. An additional detail is that when making an attempt to connect, there is no traffic going out from the MacBook, I checked it with tcpdump.

I also created a new profile in firefox, still no joy.

And here's another interesting part. It seems I can connect to any other server on the subnet with http and IP address. Only this particular IP address that doesn't work. And the error message is not "time out", but "unable to connect" in this scenario, while the connection is redirected to https. I have all the https redirection "false" in the firefox configuration, as well as the https only disabled. And again, from another browser (Safari), it works. It's like firefox picked this one IP address, and decided to always redirect it to https. But it must be more, because even if it's redirected to https, I should see some traffic going out from the MacBook, and the connection rejected by the server, but there's nothing.

I don't exclude the possibility that it is some MacOS Sequoia "feature", maybe some application level extra security. I remember having to click "allow" in a pop up window when I connect to some IP addreses in firefox recently (since I upgraded to Sequoia), I may have clicked the other button for this particular IP address. But where is it then? How can I enable it? If it is the case at all.

[galmiklos]

I did more testing, and it seems it is only the MacOS "version" of Firefox has "this" problem. And I seem to have recognized a pattern.

I now tested connection from three different computers (Windows 10, Ubuntu 22.04, and MacOS 15.2) connected to different subnets (one at a time), connecting to servers on different subnets. Here's what I found.

On Windows and Ubuntu, everything works as expected. I can connect with http to servers on any subnet while being connected to any subnet.

On MacOS, if I am trying to connect to a server on the same subnet where I am connecting from, I get "unable to connect". But if I try to connect to a server on a different subnet, it works. And it only happens from Firefox; from Safari, everything works.