WebRTC bypasses Network settings & proxy.onRequest
Categories
(Core :: WebRTC, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox109 | --- | fixed |
People
(Reporter: eros_uk, Assigned: bwc)
References
Details
Attachments
(1 file)
Testing conditions:
- Network Settings -> Manual proxy configuration -> HTTP Proxy (Also use this proxy for HTTPS)
- Network Settings -> Automatic proxy configuration -> PAC URL
- Using extension and
proxy.onRequestto forward ALL via a proxy
In all above situations, WebRCT leaks real IP thus bypassing aforementioned settings & API.
|
||
Updated•2 years ago
|
|
Assignee | |
Comment 1•2 years ago
|
||
If you want to set a proxy for the purpose of hiding your IP address, you can set the media.peerconnection.ice.proxy_only_if_behind_proxy pref. That should prevent the gathering of host candidates when there is a proxy configured, but let me know if that works for you.
When a user or an extension, sets proxies via Network settings or proxy.onRequest, the expectation is to proxy all network communications.
WebTRC seems to fall outside above processes.
Users on general are not expected to edit about:config.
AFA extensions, I am not sure if media.peerconnection.ice.proxy_only_if_behind_proxy is accessible to the extensions.
|
|
Assignee | |
Comment 3•2 years ago
|
||
I'm pretty sure extensions have the ability to access/set prefs. As for expectations, webrtc deals with UDP networking (primarily), which is substantially degraded when it is forced through a TCP hop (to the web proxy). See the following:
https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-12#section-5.1
But, we realize that users and extension authors may want to make this performance tradeoff for privacy reasons, hence the existence of the pref.
|
|
Assignee | |
Comment 4•2 years ago
|
||
It would probably be worthwhile to expose a checkbox or something on about:preferences someday, to make the pref a little easier to discover for users.
I'm pretty sure extensions have the ability to access/set prefs.
AFA extension API, there is privacy.network.webRTCIPHandlingPolicy
browser.privacy.network.webRTCIPHandlingPolicy.get({})
.then(console.log)
/*
{
"levelOfControl": "controllable_by_this_extension",
"value": "default"
}
*/
The common practice is to set default_public_interface_only which in ext-privacy.jss#148 translates to:
prefs["media.peerconnection.ice.default_address_only"] = true;
prefs["media.peerconnection.ice.no_host"] = true;
Would those settings suffice or should disable_non_proxied_udp be set? e.g.
prefs["media.peerconnection.ice.default_address_only"] = true;
prefs["media.peerconnection.ice.no_host"] = true;
prefs["media.peerconnection.ice.proxy_only_if_behind_proxy"] = true;
|
|
Assignee | |
Comment 6•2 years ago
|
||
I think you're probably looking for disable_non_proxied_udp.
While testing, among the available options, proxy_only was the only option that didn't leak the real IP.
default
default_public_and_private_interfaces
default_public_interface_only
disable_non_proxied_udp
proxy_only
|
|
Assignee | |
Comment 8•2 years ago
|
||
(In reply to erosman from comment #7)
While testing, among the available options,
proxy_onlywas the only option that didn't leak the real IP.default default_public_and_private_interfaces default_public_interface_only disable_non_proxied_udp proxy_only
That seems like a bug; disable_non_proxied_udp should be blocking all host candidates. When I manually set my prefs like this:
I don't see any of my real interfaces being gathered. Are you referring to something other than host candidates?
|
|
Assignee | |
Comment 9•2 years ago
|
||
Doing some testing myself, and I do see STUN/TURN servers being contacted via UDP, is that what you're referring to?
|
|
Assignee | |
Comment 10•2 years ago
|
||
Hmm, I'm also seeing ICE-TCP in use. That's not right.
|
|
Assignee | |
Updated•2 years ago
|
|
Reporter | |
Comment 11•2 years ago
|
||
I have been testing with online sites e.g. https://browserleaks.com/webrtc
I have also tested on Chrome and on Chrome disable_non_proxied_udp blocks real IP leak.
PS. It might be related or not, but just in case: Bug 1791243
|
|
Assignee | |
Comment 12•2 years ago
|
||
Once the change from bug 1793612 shows up in Nightly, could you verify whether media.peerconnection.ice.proxy_only=true works properly for your configuration?
|
|
Reporter | |
Comment 13•2 years ago
|
||
Sure.... Do you know when it is going to be merged?
|
|
Assignee | |
Comment 14•2 years ago
•
|
||
Should be updated by tomorrow for sure:
https://wiki.mozilla.org/Nightly#How_does_it_update.3F_Update_interval.3F
Edit: This should have landed in time for the 22:00 UTC build, so it should be available in a couple of hours, as long as the wiki is accurate.
Edit edit: Ok, looks like it barely missed the merge? Should be available tomorrow.
|
||
Comment 15•2 years ago
|
||
The (async) proxy.onRequest extension API mentioned above registers a proxy handler via the generic nsIProtocolProxyService mechanism (in the parent), but its implementation has not been tested with non-http (e.g. see bug 1567900 for a broken case).
Is per-origin proxying of WebRTC-related requests possible? If yes, what information should be communicated to extensions via the proxy.onRequest event, and what responses are expected?
Even if per-origin proxies are not possible, please let me know if we need to change anything in the proxy.settings extension API to fully support proxying of all WebRTC-related network activity.
|
|
Assignee | |
Comment 16•2 years ago
|
||
(In reply to Rob Wu [:robwu] from comment #15)
The (async)
proxy.onRequestextension API mentioned above registers a proxy handler via the genericnsIProtocolProxyServicemechanism (in the parent), but its implementation has not been tested with non-http (e.g. see bug 1567900 for a broken case).Is per-origin proxying of WebRTC-related requests possible? If yes, what information should be communicated to extensions via the
proxy.onRequestevent, and what responses are expected?
By "per-origin proxying", I'm guessing you mean selecting the proxy to use based on the origin? I am not entirely sure what will happen under the hood, but we imitate what happens with WebSockets, so I think you should see similar behavior? We have not tested this in any way.
Even if per-origin proxies are not possible, please let me know if we need to change anything in the
proxy.settingsextension API to fully support proxying of all WebRTC-related network activity.
Again, I think this should function similarly to WebSockets, but not entirely sure.
|
|
Assignee | |
Comment 17•2 years ago
|
||
|
|
Assignee | |
Comment 18•2 years ago
|
||
|
|
Assignee | |
Comment 19•2 years ago
|
||
I was able to verify that using proxy_only_if_behind_proxy works as intended with this patch. Could you provide a second check with one of the binaries in comment 18?
|
|
Assignee | |
Comment 20•2 years ago
|
||
Try looks fine.
|
|
Reporter | |
Comment 21•2 years ago
|
||
I can test it if it appears in Nightly. I am not familiar with compiling from the binary.
|
|
Assignee | |
Comment 22•2 years ago
|
||
If you want to test with a try binary, those can be found by clicking on a green "B" (or "Bo") that corresponds to your platform, then clicking on the "Artifacts and Debugging Tools" tab on the frame that opens at the bottom of the page, and then clicking the link for the installer (target.dmg on Mac OS, target.installer.exe on Windows, target.tar.bz2 on Linux). Here are some direct links:
Mac OS: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/BTup3PUUS9Sdo7bKLfbPsg/runs/0/artifacts/public/build/target.dmg
Windows x86: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Qqwn8qkpSMCLLUg-XNMEDQ/runs/0/artifacts/public/build/install/sea/target.installer.exe
Windows x64: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/f2UihkfwSyOv33U0H7xwag/runs/0/artifacts/public/build/install/sea/target.installer.exe
Linux: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/VgFHEwceRhamFuX7k1MTlg/runs/0/artifacts/public/build/target.tar.bz2
I'll go ahead and land this, since it seems to work fine, but please let us know whether it works for you, one way or another.
|
||
Comment 23•2 years ago
|
||
|
||
Comment 24•2 years ago
|
||
| bugherder | ||
Description
•