Hacker News Reader

Comment by lovelearning | Hacker News Reader

I don't use VPNs. For me, the more alarming information here is that SOCKS and Tor proxies are also leaking IP addresses. If a SOCKS proxy is configured in browser, isn't it the browser's responsibility to ensure all outgoing traffic - including WebRTC - goes via the proxy? Are these browser bugs?

Update: Can confirm Firefox Quantum with SOCKS proxy leaks the address. Oh dear!

Update 2: I didn't realize this is how WebRTC actually works. FF even has an entire page for tweaking this stuff https://wiki.mozilla.org/Media/WebRTC/Privacy. I hate it when features like these, which atleast in my case go mostly unused, have such critical weaknesses by design and it's not announced anywhere with a big red danger sign.

View on HN

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.

t. been working in telecom for far too long

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.

SIP is one of a few protocols where two completely standard-compliant implementations are commonly unable to interop.

SOAP has this property too.

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.

FWIW, I consider the canonical implementation of SIP at this point to be asterisk.

I work on a SIP derived protocol, P25 CSSI - it has all the issues of SIP, and more!

> 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.

...

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.

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.

Lots of people in webrtc are critically concerned with the safety and privacy of their users.

obviously not that critically concerned if leaking sensitive information like this was required by the spec as drafted, and has remained uncorrected.

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.

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.

What if the entire system is configured to use Tor? Does the use of Tails mitigate this weakness?

To be safe, one must restrict output on the LAN interface to the Tor process. I'm not sure whether Tails does that by default.

I don't know either, but the web browser in Tails is Tor Browser which has webrtc disabled by default.

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.

+1 for Whonix (with Qubes OS)

I am so annoyed with this. It feels like every advance in web browser technology takes away as much as it gives. Some days, it feels like the web was better back in the HTML4 days.

Can't wait to see how WebAssembly will be used against us.

Just wait till you get a load of content rendering engines being written in (dynamicly re-obfuscated) web assembly and rendered via canvas, so users are totally locked out of modifying content loaded into them or blocking ads.

This is already being worked on.

It's being fought before it's even fully grown.

Computer vision adblockers are also being worked on.

A sad and stupid zero-sum game wasting both talent and electricity.

Any links to that? What kind of enemies of mankind are working on this? Advertisers again?

> Can't wait to see how WebAssembly will be used against us.

Have you heard of Coinhive [1]? They are using WebAssembly to mine bitcoins in the browser.

[1] https://krebsonsecurity.com/2018/03/who-and-what-is-coinhive...

On the other hand, this method might be a good way to 'pay' for using a service instead of ads, so long as it's opt-in and the user knows about it.

The weird thing for me is I'm on Firefox on my Mac and I ran all those tests and it said WebRTC is enabled, but never gave my actual factual IP address. I'm running Private Internet Access which they claim is vulnerable... So I'm not sure whose doing that test but they might have their settings a bit jacked up? If you have Private Internet Access there is an "Advanced Settings" panel where you can click on "IPv6 leak protection" it disabled IPv6 while using the VPN, seems to have been enough to fool these leak tests.

> I didn't realize this is how WebRTC actually works.

Yep. STUN is in the spec, and always has been. This has been a thing for years.

STUN is part of the story. The overall process is called Interactive Connectivity Establishment (ICE).

TIL, thank you!

It seems Firefox has resigned to some sort of role as 'token' competition to Chrome.

Most of its actions seem inexplicable and counterproductive when strong privacy and user protection should be their reason to exist and keep a dedicated user base.

The bigger problem is exploding complexity in many areas is a huge concern for open source as it's becoming increasingly impossible for small teams to implement or come up with alternatives. This is going to reduce meaningful choice and leave users at the mercy of a mix of corporate or vested interests.

https://www.privacytools.io/#webrtc

Thank you for that site. Looks like I have to become more aware of browser internals.

I tried some of the leak tests here, it seems to leak my NAT address not my nearest public IP? Can anyone chime in?

It's not even the local ip of your home network. It's the ip of the tunnel interface. I don't know how this can be misused. It's only on firefox though. On chromium, it just shows 0.0.0.0 instead.

Yes that's exactly what I see. This seems to me to be a non-issue but perhaps other configurations and VPNs behave differently? I was using my phone into my home router with OpenVPN and it showed my VPN assigned NAT address 10.x.x.x ...

> Update: Can confirm Firefox Quantum with SOCKS proxy leaks the address. Oh dear!

Did you file a bug report?

I searched for one and found some that seem to be related. Will file one today and also work on a fix, since it appears this is known from a long time and nobody has bothered to provide even a simple fix.

Cool, can you link the report here when you do?

This is why when I actually do anything with tor it's always curl -H ""

Using something as complex as firefox for anything important is just stupid.

Or just use Qubes on Tor

Or just use Whonix. Or better, Whonix in Qubes.

Why -H ""? AFAICT, it doesn't do anything.

Reply on news.ycombinator.com