Can I be clear here - I thought WebRTC was using STUN, and that would need to find the wan address of your NAT box, is that not so? If it's just the private address range, that's no biggie.
WebRTC can indeed find the WAN address if your VPN client is in your machine. If it is in your router, it can't. I would think this also applies to PFsense but I have no way of testing this. When I was doing some research about it, I found some of the developer chat was about how to use it to bypass adblockers so it is definitely something you want to totally disable if you're concerned about privacy.
I tested that. In Linux, OSX and Windows, it shows VPN exit IP and LAN IP. In my case, LAN is a VirtualBox internal network with pfSense VM as DHCP server. Maybe if your device was hitting the Internet directly, WebRTC would show a public IP address. But usually, at worst it'd be an ISP internal IP address, right?
I'm getting mixed results depending on what VPN server I'm using with the OpenVPN Windows client. None have leaked the WAN IP but sometimes I just get the LAN IP and sometimes both internal LAN and VPN exit IP. I think the VPN providers are more aware of the WebRTC leak and have fixes in place now but there is still the possibility of a badly configured server not catching it. What I'm finding with leak tests is that some servers are tighter than others, even from the same provider.
I tested with my own openvpn server, running on a VPS. Here's the server.conf: Code: local a.b.c.d port 443 proto tcp-server dev tun ca ca.crt cert server.crt key server.key dh dh2048.pem server x.y.0.0 255.255.255.0 push "redirect-gateway def1" keepalive 10 120 tls-auth ta.key 0 cipher AES-256-CBC max-clients 5 persist-key persist-tun status openvpn-status.log log openvpn.log verb 5 mute 20 WebRTC showed local LAN IP and VPN server IP.
I don't have a server config file to compare to but I just looked at the .ovpn files of the two servers I tested. The first gives me just the internal VPN LAN IP, the second both the VPM LAN and exit IPs. From the client side, the configurations are identical. Code: dev tun proto udp remote xxxxx.xxxxxxxxxxxxxx 443 resolv-retry infinite client auth-user-pass nobind persist-key persist-tun ns-cert-type server comp-lzo reneg-sec 0 verb 3 <ca> -----BEGIN CERTIFICATE----- Both servers are from the same provider, one in Italy, one in the Netherlands. The one in Italy doesn't give anything but the VPN LAN IP in a webrtc stun server test. https://diafygi.github.io/webrtc-ips/ Results: Code: Your local IP addresses: 10.4.0.6 Your public IP addresses: Your IPv6 addresses:
Maybe the server in Italy is blocking ports that WebRTC needs. Or maybe it's only allowing HTTP on port 80, and HTTPS on port 443. Or ... Maybe you could ask their tech support
Sorry, missed this STUN does find the WAN address used in NAT. But when you're connecting through a VPN, that's just the WAN address of the exit server. Your ISP WAN isn't visible through the VPN tunnel. You also get the private address range, but as you say, that's no biggie. Maybe for those who go exotic (172.29.0.* etc). But most people are at 192.168.0.* or 192.168.1.*.
It can detect home Ip-address as well as local network addresses, the results of such a requests can accessed using JavaScript, but because they are made outside the normal XML/HTTP request procedure, they are not visible in the developer console. This means that only requirement for this work is WebRTC support in the browser and JavaScript, in fact as I said all new browser already fixed that. Firefox has an toggle to entirely turn it off (but get soon another option so it can be turned on but without leaking something) and Chomium not use the -webrtc flag in the compiling arguments. Again this not shows that WebRTC is 'dangerous' it's simply as always JavaScript. More dangerous is such a thing here (already patched in latest OpenVPN) which affected directly the OS because MS changed something how DNS requests are handled. Updating to latest software is as always the key because even on gpedit.msc this toggle is not easy to find, because the name is not really understandable, especially on non-eng systems.
Yes, it may compromise also VPN users real ip-addresses. But as said it's fixed in latest browsers, even if it's turned on you need to allow javascript, just use NoScript/ScriptSafe. Or disable in FF media-peer in the options and in Chrome/Chormium this is also fixable by compiling it without -webrtc flag or use uBlock and then enable it. In latest alpha/beta/developer versions this is already by default opt-out without the necessity to break the entire protocol. Besides this the protocol is very good as I already mentioned. https://www.privacytools.io/webrtc.html https://github.com/diafygi/webrtc-ips fixed as reported e.g. over here: https://github.com/diafygi/webrtc-ips/issues/27 If all is disabled then it can't display anything. (see screenshot). But as said on OS level there are currently other problems which leak your Ip even behind VPN but this is all already fixed. The only stuff I noticed is that e.g. on OpenVPN or better the configuration file from provider you use need to set to 'block-outside-dns' as argument, because most providers not use/Include that in the configuration file.
When I was using the Chrome Dev channel along with HMPA. for awhile, http://ip-api.com/ was showing my ISP Routers static ip right beside the VPN ip until I disabled Webrtc. The latest stable Chrome doesn't, it just shows internal VPN ip without disabling webrtc, so not sure what is up with the Dev channel.
OK, consensus seems to be that WebRTC on some browsers can find ISP-assigned IP address. But maybe that's just for old browsers. And development channels. The other loose end is what sorts of setups are vulnerable. Even on my host machine, which is running the first VPN client, WebRTC with JavaScript enabled only shows the LAN IP, the VPN tunnel IP, and the VPN exit IP. But then, there are iptables rules that only allow traffic to the VPN server on eth0. So nothing running in a browser can hit other sites via eth0. So what does it take for a setup to be vulnerable? Just the lack of firewall restrictions?
You're not vulnerable if you not use the protocol, in fact only the Browser and some experimental apps already may using it, so the attack level is very low. Just ensure you update your browser and all is fine, on firewall level you not need to restrict something additional to handle it, since the request coming from the apps or the browsers and not from someone which may want to attack you, webrtc also got an additional protection for that (see there papers). So it's just hype and doesn't matter much, especially there are no final webrtc specifications so everything can be changed in the future. On firewall level I would more worry about such attacks explained over here because misconfiguration of the provider.
I don't use WebRTC. And even if I did, I'm not worried about being vulnerable.Too many layers of routers and VPNs. I just want to understand when and how people using WebRTC with VPNs are vulnerable to decloaking.
No, they not find anything by default, the page must be exploited/compromised or directly coded to do this, look at my given source link, it's explained over there. When they use WebRTC? For example using WhatsApp WebChat or Firefox Hello/webchat. As said it's a legit technique and it's already patched more or less. As now given there are much more holes which affects everyone and not only WebRTC user, but seems you completely ignore this and want to talk here about webrtc with me/us.
Well, one could just go asynchronous. Lease a VPS in a well-served geographic area, connecting via VPN(s) and paying with mixed Bitcoin. Install xorg, lxde-core, openssh-server and tightvncserver. VNC via SSH, and download whatever you want. Then get it via rsync or whatever. You could pay for content using debit cards purchased with Bitcoin.
Timing based attacks are in general a huge problem because with this you can theoretically calculate the real location of the victim. From what I know this works around 400 kilometers (currently).
The next obvious step would be to spoof network delay time. Adding some randomization to it doesn't look technically like that daunting a prospect to me and I think it would just take a bit of clever coding which would work best at the VPN server but could also be done at the client level. This is just another form of metadata to be dealt with. I've yet to see any of this implemented to foil geolocation spoofing as of yet. Netflicks is just blocking IP ranges of VPN providers and they are already getting flack for this from privacy advocates. https://torrentfreak.com/tens-of-thousands-protest-netflixs-vpn-blockade-160226/ It's not like people aren't paying Netflicks and it is a good idea to set up any media streaming devices on a separate subnet through a VPN not just for privacy but security. I've been telneting inside of one of my linux based media boxes and I'm not impressed at all with its security and I would not want it on the same network as my main business PC.
Ehh, netflix uses an ip-range because the providers usually use a known range for their services, so they not detect it by metadata, just saying. But agreed metadata are in general unfine but not that important at all because most metadata not automatically compromise the security aspect because they not always can real your real location, like e.g. font metadata. Most attacks are on layer 2 or directly on the victims PC so the things is that you can have the best VPN but you may make one mistake and get infected which possible create a tunnel and then it's pretty more dangerous.
Just wanted to clarify the assumptions about what that delay triangulation technique did/didn't do - it confused me to start for sure, and I think the terminology was a bit iffy. It's not about positively determining your location, it's more about verifying that you are where you say you are (so that they can decide whether to deliver service). It may be that you are - for example - legitimately in the US but have gone through VPNs for other reasons, or have delay, so that you are wrongly fingered. IOW, it does not provide a positive identification of your location, what it does do is to identify those who are in the location with small latency.
