On 8/9/2015 9:23 PM, Ben Bucksch wrote:
Thanks for that attempt, but that won't solve the action problems in
https://bugzilla.mozilla.org/show_bug.cgi?id=959893
The leak of local IP addresses is already being used in the wild (from
what I understand) to
a) track users (even on nytimes.com)
b) attack routers
There's no indication it's being used to attack routers - and most code
to try to interact with routers just uses a table of common router
addresses anyways. And with a little work, one can usually identify the
router for a LAN without webrtc.
The tracking being done by Nytimes can be done a myriad of other ways;
at most this makes it a smidge simpler to do. And the
programmer/company responsible for it has disabled it apparently (they
were using it to try to block click-fraud on ads). The primary real
issue is disclosure of external IPs for people using VPNs (without
blocking packets to the real network connection).
An opt-in setting is not good enough. Users need to be protected by
default.
a) Some Firefox users need to stay anonymous and thus use an HTTP
proxy or VPN tunnel. (They still want to actually use the web, so they
can't use Tor.) Leaking their local IP address is a major problem. You
cannot expect users to know about this freaky implementation detail of
WebRTC.
HTTP proxies are very poor anonymity providers.
VPNs only really provide any anonymity if set up and used correctly.
(and even then it's limited; see my messages elsewhere on rtcweb). Once
we've proven this pref using an extension, we'll likely integrate it in
some way with Private Browsing mode, which anyone wanting anonymity
should be using.
VPN providers should supply setup scripts that actually provide a secure
setup (as as secure as a VPN can get you, which is limited against the
ISP and anyone who can leverage/force the ISP (or even the country-level
gateways)).
b) An opt-in will not stop the attacks on routers.
See above. The item you link to uses fixed tables of 192.168.1.1,
192.168.8.1, etc and image fetches to poke at routers. This doesn't
need WebRTC; at *most* WebRTC makes it marginally more efficient than
simply hitting all the addresses in the code. And if they used the
"time-to-fail-the-<img>-fetch" hack, likely it would be close to as
efficient even without webrtc. And note, this code doesn't need to be
efficient - it can just keep on probing. Totally disabling webrtc would
at most merely slow this attack down, and perhaps little slowdown at all.
--
Randell Jesup
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
