1750561 - proxy.onRequest auto fallback to firefox settings when manual proxy configuration is set

Status: RESOLVED DUPLICATE of bug 1750572

(WebExtensions :: Request Handling, defect)

Description

[firefox4ever]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0

Steps to reproduce:

1. Set firefox proxy settings to any valid proxy (for example socks://127.0.0.1:9150)
2. Addon in proxy.onRequest must return some invalid proxy:

{
    type: 'socks',
    host: 'unavailable-proxy.localhost.localadomain',
    port: 1,
    failoverTimeout: 1,
    username: 'nonexistent user',
    password: 'random password',
    proxyDNS: true
};

Actual results:

Firefox tries a few times to connect to invalid proxy and after that all traffic goes through proxy set in firefox settings (127.0.0.1:9150)

Expected results:

Proxy error must be displayed.

No issues when in firefox settings Direct connections, Auto or System settings option set.

System Windows 10. Bug present in all firefox latests versions (beta, release, esr)

Why this bug is critical because ip of the main proxy set in firefox settings can leak on temporary unavailability of the proxy set by the addon (as example Mozilla official Multi Account Containers add-on)

Comment 1

[Rob Wu [:robwu]]

This specific example of failing over to the default configured proxy is similar to bug 1750572.

When multiple proxies are configured, the default is to fall back to the next one in the chain. proxy.onRequest is able to specify the default proxies to use, and the current implementation is to fall back to the previous default proxies if the proxies are invalid.

Luca's comment in bug 1750572 explains that an extension can change the defaults with browser.proxy.settings.

Whether the behavior is desired depends on the desired order of precedence: does the proxy settings from the preferences take precedence over the extension-specified proxy or not? I have no final answer now.

Comment 2

[firefox4ever]

But this is a big issue for the privacy (as example official Mozilla MAC addon).

(In reply to Rob Wu [:robwu] from comment #1)

This specific example of failing over to the default configured proxy is similar to bug 1750572.

When multiple proxies are configured, the default is to fall back to the next one in the chain. proxy.onRequest is able to specify the default proxies to use, and the current implementation is to fall back to the previous default proxies if the proxies are invalid.

Luca's comment in bug 1750572 explains that an extension can change the defaults with browser.proxy.settings.

Changing browser settings is a dirty hack. Addon must work without changing any browser settings.

Whether the behavior is desired depends on the desired order of precedence: does the proxy settings from the preferences take precedence over the extension-specified proxy or not? I have no final answer now.

But add-on can't modify this chain, only append something to it. Add-ons must have separate chain or some api to stop chaining on proxy fail.

Comment 3

[Alex Cornestean]

Hello,

I’m from QA and from my understanding after reading both this bug report and bug 1750572 is that this behavior is expected.

Can the issue be closed ?

Comment 4

[Shane Caraveo (:mixedpuppy)]

returning [{ ... proxy info ...} , null] should avoid failover to other settings or extensions.

Comment 5

[firefox4ever]

(In reply to Shane Caraveo (:mixedpuppy) from comment #4)

returning [{ ... proxy info ...} , null] should avoid failover to other settings or extensions.

*** This bug has been marked as a duplicate of bug 1750572 ***

But in this bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1750572
returning null is for direct connection, not for blocking connection.

And will be this behavior changed? I'm asking because these nulls are too non-obvious.

Comment 6

[firefox4ever]

I think more documentation must be added explaining these edge cases (null or [{ ... proxy info ... }, null])

Comment 7

[Luke Crouch [:groovecoder]]

This bug, or a related issue, seems to be causing a DNS leak where Multi-Account Containers users choosing to proxy a container thru a Mozilla VPN server?

https://old.reddit.com/r/firefox/comments/wbp8mn/firefox_multiaccount_containers_leaks_real_vpn/