Firefox | Best Practice | Loading CDNs, SDKs, etc.

[gitsteff]

Hi.
My BrokerGUI is cross loading content, i.e. from cloudfront.net. I do not want to place a rule which allows content from *.cloudfront.net in general but just in this context (if loaded from broker.tld).
Do you have any recommendation for me how to implement this behavior?
Thanks.

[TriMoon]

Do you have any recommendation for me how to implement this behavior?

That kind of behaviour can only be done via a browser extension like `uBlock Origin", which checks the origin of the request.
A firewall software does not track the higher-level interaction between connections...

in UBO, mentioned above, you can create rules to allow 3rd party access to domains depending on the 1st party, and block other accesses to those domains...

[gustavo-iniguez-goya]

@gitsteff , basically what @TriMoon said, but as you mention BrokerGUI crossloading domains, could you explain in more detail the scenario? without being specific, or with domains redacted, etc.
Just out of curiosity, to understand better the behaviour. Is the BrokerGUI a PWA/electron app? etc.

[BetweenTheKeyboardAndChair]

Opensnitch can't block by browser requesting domain. It doesn't see the request till it "hits the wire", and then all it knows is the sending process. It doesn't know what domain initiated the request.

Long shot solution:
The browsers open new processes for each tab these days, so they have different command lines. Can you create some long running tabs and set opensnitch to filter by command line?

RE: The suggestion to use UBlock Origin - TL;DR it helps. It isn't a solution anymore.

The Firefox (and Chrome) security model change a few years ago to ensure plugins and extensions can not interfere with each other or the main browser functions, meant UBlock Origin (and all other ad blockers) and UMatrix could no longer actually block all of the requests. Now they block on a "best effort". There is a LOT of leakage. This change is what prompted me to start using opensnitch. In many cases, the extensions are blocking the processing of the returned request vs. stopping the outgoing request. They still help tremendously since the blocking of a reply often stops a slew of other unwanted requests from being sent. I highly recommend UBO and uMatrix. (Same author. UMatrix is a better UI for mass blocking by domain IMO.)

If anyone does find a good domain sensitive solution, please let me know.

[gustavo-iniguez-goya]

Opensnitch can't block by browser requesting domain. It doesn't see the request till it "hits the wire", and then all it knows is the sending process. It doesn't know what domain initiated the request.

I really doubt that claim.

Could you explain in detail that behaviour with an example? For example: 1) open wireshark, 2) Change opensnitch LogLevel to DEBUG, 3) load on the browser a domain. Verify that the IP and domain appear both in wireshark as well as in the opensnitch log.

I'd recommend to delete all the rules before testing it.

Chrome and firefox, and maybe others, make use of DBus to resolve domains (not always), by querying for the domain to the local stub resolver (usually systemd-resolved). DBus uses UnixSockets, so we don't intercept that query, but we do intercept outbound UDP connections made by the stub resolver.

This would be the first time I see that we don't block browsers'/stub resolvers' DNS queries, so please, post logs, a video, or something that I can use to reproduce it.