←back to thread

I can see your local web servers

(http.jameshfisher.com)
652 points jamesfisher | 3 comments | | HN request time: 0s | source
Show context
gbuk2013 ◴[] No.20028582[source]
Judging by "ReferenceError: webkitRTCPeerConnection is not defined" message in my browser it probably uses WebRTC to get your local IP subnet. I installed an add-on to block WebRTC after I watched a presentation on this tool [1][2] and I recommend you also do this, unless you actively use WebRTC (and don't want the hassle of toggling a switch).

Unfortunately the protocol is vulnerable by design. :(

[1] https://portswigger.net/daily-swig/new-tool-enables-dns-rebi...

[2] https://www.blackhat.com/asia-19/arsenal/schedule/#redtunnel...

replies(1): >>20028794 #
phiresky ◴[] No.20028794[source]
The only thing blocking WebRTC gets you is that it hides which subnet you are on, right? As in, an attacker can still just enumerate all of the common ones (10.0.0.0/24, 192.168.0.1/24, and like 5 others) and get the same results as with WebRTC enabled. So blocking it really just slightly increases the obscurity, but not really the security.
replies(1): >>20028829 #
1. gbuk2013 ◴[] No.20028829[source]
Sure, but it helps and it is cheap. I also don't use a common subnet and enjoy uMatrix. Obscurity is a viable strategy as part of a layered defence. ;)
replies(1): >>20029204 #
2. phiresky ◴[] No.20029204[source]
True.

My main problem is that blocking WebRTC blocks some very interesting methods to "re-decentralize" the web, which are only viable if most people don't have it disabled.

replies(1): >>20031600 #
3. chatmasta ◴[] No.20031600[source]
This is a classic conflict that I’ve observed a lot. Similarly, widespread SSL pinning and app sandboxing makes it difficult to reverse engineer opaque outgoing traffic. It might be more secure, but you also cannot easily inspect what data a sandboxed, cert-pinning service is sending to the outside world.

I think it’s probably something like “security, privacy, anonymity... pick two.”