https-only mode not honoring Exceptions
Categories
(Core :: DOM: Security, defect)
Tracking
()
People
(Reporter: dparks_2, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0
Steps to reproduce:
I upgraded to FF 125.0.3, close and reopen browser
Actual results:
the browser keeps forwarding HTTP to HTTPS endpoints where the website fails to load
Expected results:
the HTTP endpoint, that is registered as an HTTPS-Exception, should have been honored and the website loaded
Environment: Pi-hole DNS server, resolving to local 192.168.0.0/16 addresses where some local services do not have certificates and are not exposed publicly. These HTTP endpoints, that are listed as HTTPS-Exceptions, all worked fine before the upgrade to FF 125.0.3.
Example: http://status.downtime.local that resolves to an Uptime Kuma docker service.
|
||
Comment 2•6 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Security' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 3•6 months ago
|
||
I don't believe we made any https-only changes in 125. We certainly didn't between 125.0.1 and 125.0.3, but I assume your "upgrade to 125.0.3" was from 124.x and that you likely missed the first couple of 125 releases.
fwiw seems to be working fine for me.
Malte: can you think of anything?
|
|
||
Comment 4•6 months ago
|
||
Is your "example" a specific real case that doesn't work (the name is literally status.downtime.local), or is it an example in the "mysite.example" sense?
If the domains are associated with an external service via DNS games (something like how Plex did it), is it possible that domain added an HSTS header forcing HTTPS upgrades? With a new release we would ship updates to our HSTS preload list, which is derived from Chrome's. You can test those domains at https://hstspreload.org.
|
|
||
Updated•6 months ago
|
|
|
||
Comment 5•6 months ago
|
||
A site-defined Strict-transport-security (HSTS) setting trumps the HTTPS-only settings, including exceptions.
Thank you @dveditz for responding.
Where a few days later and a couple of reboots, and FF appears to be working again as expected. I've been using the IP addresses for a few days and just now tried again with several FQDN endpoints --> DNS --> Nginx Reverse Proxy --> HTTP server/service and they are all working again. Not sure what the issues was, but no amount of cache clearing worked that first day after the upgrade to 125.x. And yes, I believe I upgraded from 124.x as you suggested. My endpoint example was literal, and as registered in Pi-Hole DNS as a CName record.
Just to add salt to the wound, MS Edge worked just fine, while i was having issues with FF.
I wish there was more to share, but unless there is something in the startup of FF after an upgrade, I guess you can cancel this bug request.
|
||
Comment 7•6 months ago
|
||
As you suggested, I'll close this for now. If it happens again, I am happy to help investigating this issue.
This is a good reminder though that we wanted to relax HTTPS-First (if that is what caused this bug) for both:
a) domains that resolve to a private ip (bug 1858892)
b) domains that do not end with a valid tld (I've just filed bug 1896083 for that)
Thank you for the support @mjurgens.
As a homelab maintainer, and enterprise DevOps engineer professionally, I support that conversation. Any browser should recognize RFC1918 and known non-TLD endpoints and should always follow the HTTP or HTTPS port value that was originally passed.
IoT devices make a stronger case for this as well when certificates don't exist locally even if the device is using port 443. Users want to connect their light bulb and not be confused with security warnings. (they become numb to them and don't weigh them when needed on public sites)
I know from configuring web hosts and reverse-proxies that the engineers can choose port 80 or 443 depending on their need. And on local/lan/enterprise environments, browsers should not be second guessing the host bindings. This may have been a reason my company removed FF as an enterprise supported browser. The redirects became problematic, and we all know enterprises move slower than the public. In recent years we've ramped up the use of certificates internally and FQDN but Firefox has not reentered our ecosystem.
I started following those bugs you listed above. I'm very interested in the discussion. Thanks again.
Description
•