Open Bug 1918915 Opened 1 year ago Updated 1 month ago

don't upgrade mixed content for resources from `dom.securecontext.allowlist` sites (was: the pictures of the sites on this server are no longer displayed)

Categories

(Core :: DOM: Security, defect, P4)

Product:
Core
Component:
DOM: Security
Version:
Firefox 130
Type:
defect

Tracking

()

People

(Reporter: bugzilla, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: good-next-bug, Whiteboard: [domsecurity-backlog2])

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

Steps to reproduce:

A server on my local network required access to the microphone to use Whisper with Open Web UI (both are running locally on the same server). This wouldn't work with http connection unless I add the IP address the server to the preference "dom.securecontext.allowlist". FYI authorizing access to the microphone manually vis "Page Info" & "Permissions" do not resolve the issue.

Actual results:

when I add the IP of the server to the "dom.securecontext.allowlist", the microphone access work as expected, but now Firefox no longer display the pictures of all the site hosted on this server. No error message appear, just the images are not showing up. If I remove the IP from "dom.securecontext.allowlist" everything go back to normal.

Expected results:

The hosted sites should display the images.

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

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core
Component: DOM: Core & HTML → DOM: Security

Ah, good find. As part of "mixed content upgrading", we are using HTTPS for all included img, audio and video elements. of course, that doesn't work for websites that aren't actually on HTTPS but just a different kind of Secure Context (like localhost or your supplied IP address). We should exempt those from upgrading.

This should be a relatively easy fix and I'd be happy to mentor someone implementing this. The current code looks at the content type and the secure-context information, but not at the overrides from the pref.

A simple if in the right code location (plus a mochitest that re-implements this case in HTML/JavaScript) should be enough..

Blocks: mixed-content-level2
Severity: -- → S4
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P4
Whiteboard: [domsecurity-backlog2]

To fix your immediate problem, you could flip the security.mixed_content.upgrade_display_content to false.

(In reply to Frederik Braun [:freddy] from comment #3)

To fix your immediate problem, you could flip the security.mixed_content.upgrade_display_content to false.

Indeed it works. Thanks!

See Also: → 1919170

This is caused by the same bug as the similar problem with the .onion domain allowlist pref. Both were noticed because of the upgrade_display_content change, but they've been broken for the CSP upgrade-insecure-requests feature for a long time apparently. That isn't a commonly-used feature, and the sites that use it aren't going to include private network or .onion site images. I'm not surprised no one noticed until now :-)

Hello, I'm a new contributor. I tried to reproduce this bug but the images load fine for me. Is this still an issue?

My steps:

  1. Ran php -S 127.0.0.1:8000 serving a simple HTML page with an <img> tag
  2. Navigated to http://127.0.0.1:8000/
  3. Went to about:config and created dom.securecontext.allowlist as a String with value 127.0.0.1
  4. Verified security.mixed_content.upgrade_display_content is set to true
  5. Reloaded the page

Results:

  • Image still load successfully
  • Checking the Network tab shows images are requested via HTTP (not upgraded to HTTPS)

Testing environment:

  • Firefox version: 145.0
  • Platform: macOS Tahoe 26.1 (M1)
Flags: needinfo?(fbraun)

(In reply to Dominique from comment #6)

Hello, I'm a new contributor. I tried to reproduce this bug but the images load fine for me. Is this still an issue?

My steps:

  1. Ran php -S 127.0.0.1:8000 serving a simple HTML page with an <img> tag
  2. Navigated to http://127.0.0.1:8000/
  3. Went to about:config and created dom.securecontext.allowlist as a String with value 127.0.0.1
  4. Verified security.mixed_content.upgrade_display_content is set to true
  5. Reloaded the page

Results:

  • Image still load successfully
  • Checking the Network tab shows images are requested via HTTP (not upgraded to HTTPS)

Testing environment:

  • Firefox version: 145.0
  • Platform: macOS Tahoe 26.1 (M1)

I think your test succeeded because it was dealing with 127.0.0.1 specifically.
https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts#potentially_trustworthy_origins

When I add a domain pointing to my forgejo instance to the dom.securecontext.allowlist all icons/logos disappear and warnings like these are logged:

  • Mixed Content: Upgrading insecure display request ‘http://git.domain.mytld/avatars/754853f602473dae931a2cb9d74fc7g0?size=48’ to use ‘https’
  • Mixed Content: Upgrading insecure display request ‘http://git.domain.mytld/assets/img/favicon.svg’ to use ‘https’

Note that this domain is also added to the HttpAllowList policy so all other requests not related to mixed content get exempt correctly:

  • HTTPS-Only Mode: Not upgrading insecure request “http://git.domain.mytld/” because it is exempt.
  • HTTPS-Only Mode: Not upgrading insecure request “http://git.domain.mytld/assets/js/index.js?v=13.0.1” because it is exempt.

I expect mixed content to be exempt too in this case.

To make the impact of this issue is clear: Is there a reason why you cannot use HTTPS with a self-signed certifcate?

Flags: needinfo?(fdmail.3qn99)
Flags: needinfo?(fbraun)

(In reply to Simon Friedberger [:simonf] from comment #8)

To make the impact of this issue is clear: Is there a reason why you cannot use HTTPS with a self-signed certifcate?

In this example case where I own the service in question, I indeed am able to set up TLS with a self-signed certificate.
But in this case communication is done over a completely end to end encrypted network so this would introduce unnecessary double-encryption. Not to mention the annoying Firefox pop-up triggered by self-signed certificates.

Unfortunately even this "solution" is not possible when the service you want to access is hosted by a friend or a stranger who did not set up TLS with a self-signed certificate.
Connections are still encrypted by the network so there is no real need to set up TLS other than to appease browsers like Firefox.
As a result - nobody does that and they are correct in doing so.

This means you can't use secure context features like for example microphone/camera access on websites hosted on encrypted networks.

Flags: needinfo?(fdmail.3qn99)

(In reply to Vincent Rhodes:vrhodes from comment #9)

Connections are still encrypted by the network so there is no real need to set up TLS other than to appease browsers like Firefox.

I am not sure what kind of network you are assuming but no, in general, network connections are not encrypted.

(In reply to Vincent Rhodes:vrhodes from comment #9)

Unfortunately even this "solution" is not possible when the service you want to access is hosted by a friend or a stranger who did not set up TLS with a self-signed certificate.

The point is that whoever set up the service has the option to use HTTPS and thus avoid this problem.

(In reply to Simon Friedberger [:simonf] from comment #11)

(In reply to Vincent Rhodes:vrhodes from comment #9)

Connections are still encrypted by the network so there is no real need to set up TLS other than to appease browsers like Firefox.

I am not sure what kind of network you are assuming but no, in general, network connections are not encrypted.

(In reply to Vincent Rhodes:vrhodes from comment #9)

Unfortunately even this "solution" is not possible when the service you want to access is hosted by a friend or a stranger who did not set up TLS with a self-signed certificate.

The point is that whoever set up the service has the option to use HTTPS and thus avoid this problem.

Sure there are ways to not be impacted by it. Frederick shared one early on.
Not sure where this discussion is going. Are you telling this bug is not a bug?

(In reply to Simon Friedberger [:simonf] from comment #11)

Connections are still encrypted by the network so there is no real need to set up TLS other than to appease browsers like Firefox.

I am not sure what kind of network you are assuming but no, in general, network connections are not encrypted.

Well, if by in general you mean plain internet then that's correct, but I wasn't talking about that.
Here are some examples of networks that are encrypted (unlike internet):

TLS encryption is redundant on top of them because every request sent over them is already end-to-end encrypted.

(In reply to Simon Friedberger [:simonf] from comment #11)

Unfortunately even this "solution" is not possible when the service you want to access is hosted by a friend or a stranger who did not set up TLS with a self-signed certificate.

The point is that whoever set up the service has the option to use HTTPS and thus avoid this problem.

Why are you are assuming that the user is also always the provider of the service even though you are replying directly to the sentence where I said that it's not always the case? Providers of the services are not wrong for not having TLS on an end-to-end encrypted network therefore nobody can logically convince them to set it up by arguing in good faith. And that's assuming they kindly leave contact details somewhere.

If I told someone to set up TLS on their service because my Browser has a bug that forces me to either loosen security to fix mixed content or not have secure context features at all on their service, they would simply tell me to fix my Browser and I would have nothing else to say because they are completely right.

Tor Browser developers knew that they shouldn't try to convince the whole end-to-end encrypted Tor Network to use self-signed TLS certificates for no reason other than a bug in Firefox like you seem to suggest now.
And it's not like they would be able to do that even if they tried to.

Instead Tor Browser developers had to hard-code a workaround that exempts the .onion top level domain of the Tor network from mixed content warnings.
This isn't a fix for this bug, merely a way to avoid it's consequences completely as long as you are using Tor Browser with .onion domains.
And they wouldn't have to do this if this bug didn't exist.

But not every network project is like Tor and can afford to maintain a fork of Firefox with custom patches to ignore Firefox's bugs that should have been fixed upstream long time ago, nor should they. And even if they did do it, it would be very inconvenient for users to have 5 Firefox forks installed for every mesh network they want to interact with, all with different patches that avoid a single Firefox bug in a slightly different way.

Considering all of this, it almost seems like setting security.mixed_content.upgrade_display_content to false and accepting the risk is a good deal considering what you have to go through otherwise to just use secure context features with mixed content working at the same time.

That's why the bug should simply be fixed in Firefox so Firefox could be configured to be able to interact with all of the networks at the same time securely and without compromises, maintaining forks or recompiling it with your own custom patches.

I've updated the summary to describe what I think the change we want is, rather than the more generic symptoms. I'm not sure if I've captured it correctly. I updated the summary assuming we want to look at the individual <img> urls and upgrade some http: sites but skip others like .onion links and sites on the allowlist. A perfectly normal https:// site might have some of those links. In otherwords, we treat the allowlist the way we automatically treat localhost/127.0.0.1

The reporter's actual case is that the document he's looking at is from a site on the allowlist. Are all the broken links pointing back to that same site? If so the above approach would fix it, but if not the user might have to add a whole bunch of additional sites. And if it's not the viewer's site or content they might have no reasonable way to know all the sites those should be. So possibly we should also skip mixed-content-upgrading if the document itself is from an allowlist site. That would be different than how we treat localhost.

Summary: when adding a the ip address of a local server to "dom.securecontext.allowlist", the pictures of the picture of the sites on this server are no longer displayed → don't upgrade mixed content for resources from `dom.securecontext.allowlist` sites (was: the pictures of the sites on this server are no longer displayed)

(In reply to Vincent Rhodes:vrhodes from comment #13)

Instead Tor Browser developers had to hard-code a workaround that exempts the .onion top level domain of the Tor network from mixed content warnings.
This isn't a fix for this bug, merely a way to avoid it's consequences completely as long as you are using Tor Browser with .onion domains.
And they wouldn't have to do this if this bug didn't exist.

But not every network project is like Tor and can afford to maintain a fork of Firefox with custom patches to ignore Firefox's bugs that should have been fixed upstream long time ago, nor should they.

We dispute your description of the Tor patch working around a "bug" in Firefox. Tor does non-standard things and it does not seem unreasonable to expect Tor developers to code adaptations for those non-standard behaviors. And that Tor patch was upstreamed to Firefox, in bug 1382359. We work with them to incorporate as many of their patches as we can. Just as we'd like to accommodate your needs as Freddy indicated in comment 2.

And even if they did do it, it would be very inconvenient for users to have 5 Firefox forks installed for every mesh network they want to interact with, all with different patches that avoid a single Firefox bug in a slightly different way.

Considering all of this, it almost seems like setting security.mixed_content.upgrade_display_content to false and accepting the risk is a good deal considering what you have to go through otherwise to just use secure context features with mixed content working at the same time.

That's why the bug should simply be fixed in Firefox so Firefox could be configured to be able to interact with all of the networks at the same time securely and without compromises, maintaining forks or recompiling it with your own custom patches.

You need to log in before you can comment on or make changes to this bug.