This is the fault of the browser and WebRTC. They know about this but deliberately break it. The truth is WebRTC should never activate without user permission.
But no, WebRTC added data-channels. They have no good use to be silent and especially not to override SOCKS proxy. In fact, some key people on the WebRTC group, when I pressed them, could not provide a single real use-case for silent data channels.
Firefox is absolutely in the wrong to ignore your proxy settings, especially without getting consent first to start a call. It's a complete mess. Regardless of what the "spec" says, Firefox is responsible for implementing broken software that harms users.
Then again, so is STUN/ICE and basically every single thing that has to do with SIP/VoIP. It's like they go out of their way to be obtuse and come up with shitty standards then take glee in how bad it gets. As an example, look up SIP Torture Tests. There's an RFC just to illustrate the moronic edge-cases in SIP parsing that at one point implies your software needs to be conscious to infer the intention of malformed messages.
Yes, this is largely the browser's problem. Because all available uplinks are available. Tor browser doesn't leak, because WebRTC is blocked. But other browsers with WebRTC enabled will leak with a standard Tor setup.
However, using Whonix for Tor, even if you install a random browser with WebRTC enabled, there is no WebRTC leak. Because the workstation VM has no Internet access except through Tor. The gateway VM is not a router. There is no forwarding, and it's firewalled. It just exposes Tor ports to a private internal network, for the workstation VM.
And one can do the same for VPNs, using pfSense VMs as VPN gateways. Apps in workspace VMs have no Internet access except through the VPN client running in the gateway VM.
TBH just from setting up one (1) PBX with about half a dozen devices from only two manufacturers -- I would never take a job anywhere near anything having something todo with SIP, ever.
Oh it gets better. I have implemented SIP software (written, from scratch). On the SIP implementors mailing list, one of the authors defends the insane parsing rules by saying that C and Java allow you to be flexible with syntax, so why not SIP?
They are totally detached from actually implementing elegant or high performance software. Actual engineers achieve this despite of SIP's terrible decisions. Granted, many of those are inherited from HTTP. Tell me how many HTTP stacks handle comments and line folding properly...
It opens up security holes, too. One proxy interprets \r\r\n as 1 line break, another as 2 line breaks and start of body. Oops, now you can end up sending fun headers to your target because they try to be flexible in accepting input.
IIRC there is essentially no way to implement SIP standardly because of so many broken implementations. You have to make some decisions on certain parsing that will break one but any other way will break another.
Text-based protocols invite abuse by designers and implementors alike. IETF compounds these by living in a fantasy world.
> I'm not sure binary protocols are any better, unless you make the first two bytes of every message a version number.
Actually we've seen people manage to fuck that up royally, too. Examples: Routers confusing MAC addresses starting with "6" with IPv6 packets. Various TLS implementations in proxies falling completely apart when they see an unknown version. Various TLS proxies falling apart when seeing an unknown extension. Far too many instances of "assert version==1" to list.
VoIP phones sometimes just don't work with some destination numbers (OWA/jumbled audio/insta-disconnect/no-connection). Workaround: call with mobile phone.
My impression is that this is a conflict between the WebRTC folks and the UX folks. The WebRTC team is happy to prompt you to use data channels, but the UX team doesn't want to over saturate people with security warnings. Especially warnings that people wont understand.
I'm only going off some in-person dealing with folks behind WebRTC and they know that permissions suck and would hurt adoption and hence fight to make sure they don't happen.
They dismiss all privacy concerns with "you can't have privacy in a browser" and "fingerprinting will work anyways so we can't make it worse". It's head-in-sand approach to privacy and it's bad.
Even then, Firefox is simply wrong to tell people it'll use your proxy, then throw that out.
I'm not sure what that means. It was obvious this would be used for fingerprinting and leaks. The explained reasons for proceeding was that permission prompts for data channels would hurt usage, despite not having clear cases where we need P2P without letting users know.
And none of this excuses overriding the user's expressed network connectivity.
When this was brought up, they immediately jumped to the excuses that fingerprinting can't be helped. And many jumped to saying hey you should use Tor Browser anyway. Total capitulation.
Maybe someone cared, but it's not the official stance from webrtc groups or browsers.
It really seems like adding a permission handler with a warning on WebRTC would be an easy fix for this problem and/or browsers should respect proxies and such when generating WebRTC candidates.
And I say that as someone who thinks WebRTC has some pretty cool use cases.
I use wrbrtc for lossy robot pose data. It would suck to require another approval popup in my software, but really, it's no big deal. Certainly the UX cost is worth the security benefits if we can't have both.
But no, WebRTC added data-channels. They have no good use to be silent and especially not to override SOCKS proxy. In fact, some key people on the WebRTC group, when I pressed them, could not provide a single real use-case for silent data channels.
Firefox is absolutely in the wrong to ignore your proxy settings, especially without getting consent first to start a call. It's a complete mess. Regardless of what the "spec" says, Firefox is responsible for implementing broken software that harms users.
Then again, so is STUN/ICE and basically every single thing that has to do with SIP/VoIP. It's like they go out of their way to be obtuse and come up with shitty standards then take glee in how bad it gets. As an example, look up SIP Torture Tests. There's an RFC just to illustrate the moronic edge-cases in SIP parsing that at one point implies your software needs to be conscious to infer the intention of malformed messages.
t. been working in telecom for far too long