6 ms·

Just a friendly reminder for anyone using uBlock Origin on Chrome or Firefox that you can now configure it to prevent webRTC from leaking your real IP: http://

Just a friendly reminder for anyone using uBlock Origin on Chrome or Firefox that you can now configure it to prevent webRTC from leaking your real IP: http://www.ghacks.net/2015/07/02/you-can-block-webrtc-from-leaking-your-ip-now-in-ublock-origin/ http://www.ghacks.net/2015/07/02/you-can-block-webrtc-from-l... You do need to enable this. After reading the article I immediately checked by dashboard and saw that the option was available, but unchecked.

TD-Linux 11y ago
When I visit the NYT, it gets a full IPv6 address, non-NAT. Isn't this just as bad? Should we tell everyone to turn off IPv6 support?
- p1mrx 11y ago
  Technically www.nytimes.com doesn't see your IPv6 address, because the site is still IPv4-only.
- harshreality 11y ago
  If you want to hide the IP you're connecting from, and you want to use IPv6, then you have to find an IPv6-enabled VPN (or make one yourself with a cheap vps). The major use case for webrtc ip leak blocking is preventing leaking of rfc1918 IPs (or link/site-local IPv6 addresses) and preventing leaking of alternate LAN and alternate public IPs. For example, if you web browse through a VPN, this webrtc functionality will by default reveal not only your public VPN exit IP, but also your VPN rfc1918 ip, and also your real rfc1918 ip, and your primary, non-vpn public IP. All in the name of better connectivity for webrtc. It's horrible. I don't understand why webrtc does this. How does revealing non-global addresses help improve (edit: reliably improve) connectivity? Those addresses aren't guaranteed to be globally unique, so if you have two webrtc app users on the same non-global netblock, so what? Even if they have the same public IP, it's not guaranteed that they can talk to each other with their non-global addresses; they could be on different (isolated) internal networks. So the app will be blindly trying to connect to random internal ip addresses. Sounds fun for NIDS.
  - cbhl 11y ago
    Doesn't it help if two people are sitting right next to each other behind the same NAT?
    - makomk 11y ago
      It's necessary if the NAT device doesn't support hairpinning. Unfortunately, historically many didn't, so users couldn't connect to other users on the same NAT using their public IPs, even with techniques that worked fine for connecting to other identical NAT setups elsewhere.
      - MichaelGG 11y ago
        Is it necessary? You could do a broadcast on the LAN if the public IP is the same.
        nitrogen 11y ago
        That same-subnet local IPs behind one public IP can reach each other is probably not a safe assumption to make.
        MichaelGG 11y ago
        You only send a broadcast to attempt to reach the other party. If it does not work, you fallback to the public IP. This is sorta what ICE does already.
        profmonocle 11y ago
        It's not safe to assume that multiple clients behind the same public IP are on the same LAN. At my office, wired and wireless clients NAT to the same public IP, despite being on different subnets. Plus, thanks to IPv4 depletion there might be multiple layers of NAT involved, because ISPs are having to deploy carrier-grade NAT.
  - meowface 11y ago
- the8472 11y ago
  With ipv6 there are the privacy extensions[1] for SLAAC which will assign your computer a new v6 address from your network prefix in a regular interval. This is enabled by default on windows, osx and some linux systems. But I do wonder whether webrtc can find your other v6 addresses, a host often has more than one. [1] https://tools.ietf.org/html/rfc4941 https://tools.ietf.org/html/rfc4941
ihuman 11y ago
I'm surprised that isn't enabled by default. I hope that the developer changes that in the future.
- Nexxxeh 11y ago
  Presumably it breaks stuff.
  - tagawa 11y ago
    Yes, sharing IP addresses is needed for P2P communication to work so enabling this blocking option would also block legitimate uses of WebRTC such as video chat (e.g. https://talky.io https://talky.io , https://appear.in https://appear.in , etc.) and low-latency data sharing.
mahouse 11y ago
After enabling it I keep seeing my public address here. https://diafygi.github.io/webrtc-ips/ https://diafygi.github.io/webrtc-ips/ — What gives?
- funkyy 11y ago
  But it wont be able to see your IP once hidden behind VPN or Proxie server.
  - mahouse 11y ago
    That's bad. I expect to see there only an IP address obtained by using WebRTC, not a detection by using all methods that are possible.
- satori99 11y ago
  That is odd... for me (Firefox on Windows), enabling that option completely removes the `RTCPeerConnection` property from the global object, and any script that tries to use it fails with `TypeError: RTCPeerConnection is not a constructor`.
- sergers 11y ago
  i was having the same issue. enabling the option in ublock origin, my local IP would not show but my "Public" IP address still showed. decided to checkout what options are in chrome://flags for webrtc (use to be enable/disable for webrtc but now thats restricted to just android). found this other option in the flags, chrome://flags/#enable-webrtc-stun-origin Enable support for WebRTC Stun origin header. Mac, Windows, Linux, Chrome OS, Android When enabled, Stun messages generated by WebRTC will contain the Origin header. i enabled it, my public IP no longer shows on that site. doesnt matter if i disable/enable ublock, my public IP never shows on that site with that chrome flag enabled. any idea what that flag actually does? and repercussions leaving it enabled?
- pmontra 11y ago
  I went there with Firefox without ublock and saw my public and local addresses (docker0, eth0 and virbr0 - VirtualBox). I installed Disable WebRTC https://addons.mozilla.org/en-US/firefox/addon/happy-bonobo-disable-webrtc/ https://addons.mozilla.org/en-US/firefox/addon/happy-bonobo-... and all the addresses disappeared. NoScript mitigates the problem because WebRTC won't work with scripts blocked but I'll still have to disable the plugin to make it work on legitimate sites. It's annoying and I'd prefer a browser permission popup along the lines of what has been suggested in other posts here.
funkyy 11y ago
That is very helpful. Thank you for rising the awareness!

TD-Linux 11y ago

When I visit the NYT, it gets a full IPv6 address, non-NAT. Isn't this just as bad? Should we tell everyone to turn off IPv6 support?

p1mrx 11y ago
Technically www.nytimes.com doesn't see your IPv6 address, because the site is still IPv4-only.
harshreality 11y ago
If you want to hide the IP you're connecting from, and you want to use IPv6, then you have to find an IPv6-enabled VPN (or make one yourself with a cheap vps). The major use case for webrtc ip leak blocking is preventing leaking of rfc1918 IPs (or link/site-local IPv6 addresses) and preventing leaking of alternate LAN and alternate public IPs. For example, if you web browse through a VPN, this webrtc functionality will by default reveal not only your public VPN exit IP, but also your VPN rfc1918 ip, and also your real rfc1918 ip, and your primary, non-vpn public IP. All in the name of better connectivity for webrtc. It's horrible. I don't understand why webrtc does this. How does revealing non-global addresses help improve (edit: reliably improve) connectivity? Those addresses aren't guaranteed to be globally unique, so if you have two webrtc app users on the same non-global netblock, so what? Even if they have the same public IP, it's not guaranteed that they can talk to each other with their non-global addresses; they could be on different (isolated) internal networks. So the app will be blindly trying to connect to random internal ip addresses. Sounds fun for NIDS.
- cbhl 11y ago
  Doesn't it help if two people are sitting right next to each other behind the same NAT?
  - makomk 11y ago
    It's necessary if the NAT device doesn't support hairpinning. Unfortunately, historically many didn't, so users couldn't connect to other users on the same NAT using their public IPs, even with techniques that worked fine for connecting to other identical NAT setups elsewhere.
    - MichaelGG 11y ago
      Is it necessary? You could do a broadcast on the LAN if the public IP is the same.
      - nitrogen 11y ago
        That same-subnet local IPs behind one public IP can reach each other is probably not a safe assumption to make.
        MichaelGG 11y ago
        You only send a broadcast to attempt to reach the other party. If it does not work, you fallback to the public IP. This is sorta what ICE does already.
      - profmonocle 11y ago
        It's not safe to assume that multiple clients behind the same public IP are on the same LAN. At my office, wired and wireless clients NAT to the same public IP, despite being on different subnets. Plus, thanks to IPv4 depletion there might be multiple layers of NAT involved, because ISPs are having to deploy carrier-grade NAT.
- meowface 11y ago
the8472 11y ago
With ipv6 there are the privacy extensions[1] for SLAAC which will assign your computer a new v6 address from your network prefix in a regular interval. This is enabled by default on windows, osx and some linux systems. But I do wonder whether webrtc can find your other v6 addresses, a host often has more than one. [1] https://tools.ietf.org/html/rfc4941 https://tools.ietf.org/html/rfc4941

ihuman 11y ago

I'm surprised that isn't enabled by default. I hope that the developer changes that in the future.

Nexxxeh 11y ago
Presumably it breaks stuff.
- tagawa 11y ago
  Yes, sharing IP addresses is needed for P2P communication to work so enabling this blocking option would also block legitimate uses of WebRTC such as video chat (e.g. https://talky.io https://talky.io , https://appear.in https://appear.in , etc.) and low-latency data sharing.

mahouse 11y ago

After enabling it I keep seeing my public address here. https://diafygi.github.io/webrtc-ips/ https://diafygi.github.io/webrtc-ips/ — What gives?

funkyy 11y ago
But it wont be able to see your IP once hidden behind VPN or Proxie server.
- mahouse 11y ago
  That's bad. I expect to see there only an IP address obtained by using WebRTC, not a detection by using all methods that are possible.
satori99 11y ago
That is odd... for me (Firefox on Windows), enabling that option completely removes the `RTCPeerConnection` property from the global object, and any script that tries to use it fails with `TypeError: RTCPeerConnection is not a constructor`.
sergers 11y ago
i was having the same issue. enabling the option in ublock origin, my local IP would not show but my "Public" IP address still showed. decided to checkout what options are in chrome://flags for webrtc (use to be enable/disable for webrtc but now thats restricted to just android). found this other option in the flags, chrome://flags/#enable-webrtc-stun-origin Enable support for WebRTC Stun origin header. Mac, Windows, Linux, Chrome OS, Android When enabled, Stun messages generated by WebRTC will contain the Origin header. i enabled it, my public IP no longer shows on that site. doesnt matter if i disable/enable ublock, my public IP never shows on that site with that chrome flag enabled. any idea what that flag actually does? and repercussions leaving it enabled?
pmontra 11y ago
I went there with Firefox without ublock and saw my public and local addresses (docker0, eth0 and virbr0 - VirtualBox). I installed Disable WebRTC https://addons.mozilla.org/en-US/firefox/addon/happy-bonobo-disable-webrtc/ https://addons.mozilla.org/en-US/firefox/addon/happy-bonobo-... and all the addresses disappeared. NoScript mitigates the problem because WebRTC won't work with scripts blocked but I'll still have to disable the plugin to make it work on legitimate sites. It's annoying and I'd prefer a browser permission popup along the lines of what has been suggested in other posts here.

funkyy 11y ago

That is very helpful. Thank you for rising the awareness!