WebRTC leaks UDP traffic outside socks5 proxy

This seems to describe a similar behaviour in Brave: https://community.brave.com/t/webrtc-doesnt-use-configured-proxy-regardless-of-ip-handling-policy-setting/399372

@ruihildt out of curiosity does this behaviour happen on all platforms?

Only tested on Linux, will look at it further at a later point in time.

added Bug Roadmap::Future labels

I recommend flipping media.peerconnection.ice.proxy_only_if_behind_proxy to true and repeating this test, this forces proxied UDP when a proxy is in use. media.peerconnection.ice.proxy_only also exists but it might block WebRTC completely if no proxy is configured.

You might also be interested in media.peerconnection.ice.default_address_only, which is particularly good when using a VPN. Me and @thorin tested this a while back and I used Mullvad during the whole test and my private IP address was never exposed (assuming there's a need beyond mDNS being used for ICE candidates in most cases). If no VPN is in use however, the private IP address might still be grabbed in some scenarios (eg. camera and mic are used for video conferencing).

I recognize you decided for media.peerconnection.ice.relay_only but you can cut the middle man (the relay) and generate external candidates instead.

A good reference: https://wiki.mozilla.org/Media/WebRTC/Privacy

added All Platforms label

removed Roadmap::Future label

added Next label

assigned to @ma1

@ruihildt, @fabrizio's suggestions seems sound.

Could you please check whether turning media.peerconnection.ice.default_address_only to true in about:config suffices to "fix" all our use cases (i.e. just expose the VPN's exit portal in all your test scenarios)? Thanks!

OK, I performed some tests myself and it seems the most sensible thing to do here is:

media.peerconnection.ice.relay_only -> false
media.peerconnection.ice.default_address_only -> true
media.peerconnection.ice.proxy_only_if_behind_proxy -> true

Creating a patch

noice :-)

just for confirmation, is it ok that with this setup the private IP address of the user might still be exposed when no VPN is in use? I would say it's ok since it only happens in trusted scenarios (mic and camera permissions allowed) AND when the VPN is not used, but I wanted to make sure because my previous comment wasn't the clearest.

is it ok that with this setup the private IP address of the user might still be exposed when no VPN is in use?

I believe this is covered by media.peerconnection.ice.obfuscate_host_addresses being true.

Actually that is not always the case, check dom/media/webrtc/jsapi/PeerConnectionImpl.cpp and the IsActivelyCapturingOrHasAPermission method; so at that point a VPN really makes all the difference.

A similar approach is present in Chrome.

So, to recap:

With the proposed changes VPN users only expose their external IP. When no VPN is in use, LAN IPs are obfuscated to JavaScript on random pages, but revealed to pages which have been given explicit mic/cam permissions.
Setting media.peerconnection.ice.no_host would prevent any leak, but also break most video-conferencing applications.
Maybe we could keep media.peerconnection.ice.relay_only to true, but I'm under the impression that it would just move the leakage from the page which has acquired mic/cam permissions to the TURN server they've configured, while breaking applications which did not configure any TURN server. This could be mitigated by centralizing the trust recipient, if Mullvad offered its own TURN server(s) and we forced the browser to use them only, as described here, but I'm not sure how scalable it would be and if it's worth the effort, given the limited and controlled exposure scenario described in 1.

So for the time being, I'd try these changes and possibly re-evaluate option 3 later.

@ruihildt, what do you think?

mentioned in issue tor-browser#41727 (closed)

added Needs Information label

mentioned in issue tor-browser#41970 (closed)

tor-browser#41970 (closed) might be the key to understand our failed attempts to avoid UDP leaks.

For the sake of testing, I propose to flip right now the media.peerconnection.ice.default_address_only, media.peerconnection.ice.no_host and media.peerconnection.ice.proxy_only_if_behind_proxy preferences to true.

Together they provide the WebExtensions privacy API setting disable_non_proxied_udp, which after the Firefox fix referenced in tor-browser#41970 (closed) should prevent IP leaks through UDP whenever a proxy in use for the hosting page.

wfm let's do it

I think fabrizio approves, just quietly. Send him some swag too (he's helped me for a couple of years including testing FPing stuff), and a mullvad tshirt

PS: no emoji for pie, had to use a taco

@richard I would like to have it in the next alpha if possible, so we can test it properly before stable.

wfm let's do it

Doing it in tor-browser#42029 (closed)

added 13.0 stable label

removed Needs Information label

locked this issue

unlocked this issue

mentioned in issue tor-browser#42029 (closed)

added Doing label and removed Next label

marked this issue as related to tor-browser#42029 (closed)

mentioned in merge request tor-browser!731 (merged)

I tried webRTC (Jitsi, tested on meet.mullvad.net) + socks5 + MB 13.0a3 and now there's no leak, but the audio/video fails.

I have the following error: WebRTC: ICE failed, add a STUN server and see about:webrtc for more details

Is this the expected result?

yes, with media.peerconnection.ice.no_host set to true that is super common. I believe you'll have no leaks and functional video conferencing by flipping that pref.

Thanks, I'll try this setup tomorrow.

Thanks, I'll try this setup tomorrow.

Did you have any chance to check whether that might be the ultimate solution?

I got confusing results, as in this last set of changes don't leak any UDP traffic outside the tunnel. But then confusingly it seems that MB 12.5.3 also doesn't leak any UDP traffic outside the tunnel.

I'm not confident about my methodology and results, as I relied on a coworker test setup for this, and I don't have the time/knowledge to setup a proper clean environment to replicate these findings.

I'm not confident about my methodology and results, as I relied on a coworker test setup for this

@ruihildt, do you think we could/should bring your coworker back in the loop and try to figure out whether turning media.peerconnection.ice.no_host back to false as the best compromise between usable video calls and leak-proof UDP before 13.0 stable?

I'm uncomfortable being a middleman/inefficient relay for testing in this case.

An alternative course would be to postpone this testing at our upcoming meeting IRL. Does that seem acceptable to postpone these settings changes to a 13.x release?

Does that seem acceptable to postpone these settings changes to a 13.x release?

If you're asking for our "Tor point of view", I think we're perfectly fine with that as long as Mullvad is, since we don't ship the Tor Browser with webrtc enabled anyway

Therefore I'm keeping it to Needs Information and adding 13.5 stable to signify should any change be needed it will land on 13.5 alpha and possibly backported to 13.0.x.

added Needs Information label

removed Doing label

added 13.5 stable label

Another interesting case seems to be Apple's mDNS on Windows, see tor-browser#42163 (comment 2954075).

It shouldn't be a problem but we might want to check that as well.

WebRTC workshop with richard@mullvad

We tested Mullvad's Jitsi instance with Fx 119, MB 12.5.6 and MB 13.0.1, direct and over Socks5 proxy, checking for UDP leaks:

1. Fx   direct : Jitsi works, UDP leaks
2. Fx   proxied: Jitsi works, UDP leaks
3. MB12 direct : Jitsi works, UDP leaks
4. MB12 proxied: Jitsi works, UDP leaks
5. MB13 direct : Jitsi works, UDP leaks
6. MB13 proxied: Jitsi BROKE, UDP blocked

Upon further analysis, we realized behavior n. 6 MAY be the correct one, caused by Mozilla having fixed their media.peerconnection.ice.proxy_only_if_behind_proxy pref to actually try to use the proxy as a relay for UDP traffic (https://bugzilla.mozilla.org/show_bug.cgi?id=1790270). In facts, independently from all the other webrtc prefs, if we turn off proxy_only_... Jitsi starts working and UDP leaking, like in 12.5.6.

This might mean that the Socks5 proxy doesn't actually support relaying UDP (as advertised), or that Firefox is still not doing the right thing, causing the UDP traffic to be blocked rather than relayed, or both.

To start investigating these two hypothesis we configured a Torrent client which advertises Socks5 compatibility to constrain all its traffic to the tunnel, but we found this application "lied", i.e. a lot of UDP traffic leaked outside the tunnel.

Therefore we decided to proceed in parallel along 3 lines:

Open a new Mozilla bug, linked to https://bugzilla.mozilla.org/show_bug.cgi?id=1790270, about making videoconferencing actually work with media.peerconnection.ice.proxy_only_if_behind_proxy and Mullvad VPN active (of course without UDP leaks), under the assumption Mozilla VPN would benefit as well from the fix
Check whether Mullvad VPN can actually relay UDP traffic (as it was believed up to today), and if not, understand if/how this can be fixed
As a fallback (or short-term) plan, explore UX to warn user about their IP being leaked via UDP to the WebRTC infrastructure before the leak start and allow them to opt-in/opt-out the session

@ruihildt & @ma1 will take care of item 1, "richard@mullvad" is doing item 2, @ma1 is going to figure out item 3 with the UX Team.

richard@mullvad has verifier today that UDP overs socks5 is working correctly in Mullvad VPN socks5 implementation.

As far as I understood, the test made was similar to the following one: https://unix.stackexchange.com/a/744773

@ruihildt just found identified a very relevant piece of info in https://bugzilla.mozilla.org/show_bug.cgi?id=1808692#c4: neither Firefox nor Chrome currently supports UDP over SOCKSv5.

Also relevant but not necessarily a showstopper like this would be Mozbug 1416787: TURN server does not use socks proxy

So IMHO at this point we're left with two tasks:

Asking Mozilla to pretty pretty please fix the (old!) bugs above
Going ahead with our fallback plan, "explore UX to warn user about their IP being leaked via UDP to the WebRTC infrastructure before the leak start and allow them to opt-in/opt-out the session" ( /cc @donuts ?)

@ma1 opened an issue on Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1808692

Basically, UDP over proxy has not been implemented, so it's not possible to use webrtc without going outside the tunnel.

@ma1 Since UDP over socks5 is not a thing, are we happy with the settings current settings? Or do we have to modify them, to make sure Jitsi is correctly breaking?

Yes, our current settings are the correct ones to ensure UDP doesn't leak and we do best effort WebRTC.

BTW, we had a UDP/WebRTC meeting with Tor network people recently, and we came back again with the suggestion for Mullvad (and in perspective maybe Tor if sometime in the future we decide to turn WebRTC in the Tor Browser and we've got the bandwidth capacity) to provide one or more TURN servers for their users, which would allow JITSI (and possibly other services not providing their own TURN servers) to work without UDP.

Notes from that meeting so they don't disappear:

2024-02-08

Thanks stack overflow: https://stackoverflow.com/questions/59484802/ice-vs-stun-vs-turn

TURN is a relay — both clients send data to the TURN server, which forwards it to the other client.

STUN is not a relay — the STUN server helps to "make the connection" between the clients (by discovering and exchanging their external host:port pairs), after which they send data to each other directly. However, STUN doesn't work with all NAT/firewall setups, so TURN is used when STUN fails.

UDP Application Support in Tor Proposal: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/348-udp-app-support.md?ref_type=heads Mozilla's proxied UDP / WebRTC bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1808692

WebRTC supports tunneling datagrams over TCP via TURN, doesn't require UDP at all

JITSI is STUN only, no TURN; does not work without UDP (self-hosted JITSI)

next step, potentially audit existing WebRTC implementation see what it's doing in Firefox

potentially update Tor Browser's WebRTC to use own ICE server instead

Mozilla seems to be taking VPN use case into account per: https://wiki.mozilla.org/Media/WebRTC/Privacy

relevant prefs: media.peerconnection.ice.relay_only = true media.peerconnection.use_document_iceservers = false media.peerconnection.default_iceservers = [{ urls: "turn:turn.onion:3478", username: "RANDOM", credential: "GENERATED" }] media.peerconnection.enabled = true

we could potentially run our own TURN server(s) on Tor Relays/within Tor Network for apps

ma1: if/when UDP is implemented in ARTI, how will UDP be exposed to callers eg Tor Browser?

beth: basically two options: deep end-to-end UDP implementation in Tor, alternately built on top of existing Tor (eg UDP over TCP which has potential complications/lag associated with in-order/guaranteed delivery of unerlying transport; network team broadly looking to fix this problem with parallel conflux circuits)

for Mullvad, they could run their on TURN server, and the browser could somehow swap out these endpoints with Mullvad-run TURN servers

where to followup:

Network UDP Working Group meetings on Thursdays

1500 UTC on Wednesdays -> https://tor.meet.coop/ale-div-esn-4vf

Thank you for all these informations.

It could make sense for us to try running a TURN servers for users connected to Mullvad VPN, but I would need to better understand how that is possible to implement on the browser side. (and also a STUN server, but this is easy and not resource heavy at all)

In any case, I'm happy to close this issue, since it has been addressed as far as I'm concerned.

@ma1 / @richard Could you open another issue with the suggested TURN scenario and what would be needed on browser/side and on the infra side?

I'm afraid I don't know enough to do a good job explaining this.

@morgan / @ma1 Revisiting this issue, it seems my last requested was forgotten, is that something you could do?

There was also the suggestion from @ma1 to "explore UX to warn user about their IP being leaked via UDP to the WebRTC infrastructure before the leak start and allow them to opt-in/opt-out the session".

Should that also be turned into a separate issue?

@ma1 re re-routing TURN traffic to a Mullvad server, since TURN is a meetingpoint/relay would other clients also need to know about this TURN server? Would TURN-based WebRTC work from Mullvad Browser to a non-Mullvad Browser?

@morgan AFAIK, TURN is a standard (RFC 8656) and it's used automatically by ICE (another standard used by WebRTC) when STUN doesn't work it.

So, since they all are standard protocols they should work.

However, I think apps provide their TURN servers, rather than the browser (at least apps have to provide the address of ICE servers).

closed

WebRTC leaks UDP traffic outside socks5 proxy

Designs

Child items 0

Activity

WebRTC workshop with richard@mullvad