Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Abusing WebRTC to reveal coarse location data in Signal

medium.com

Post reply on HN
Print view View original

41–50 of 64 posts

Re: Abusing WebRTC to reveal coarse location data in Signal

#41

Post by stagas »

skybrian wrote: post #29
DrPhish wrote: post #17

The only universal fix I can think of for this class of attacks is to have routers bound latency to a lower limit (eg. 200ms), with fixed latency buckets (eg. 500ms granularity) when it goes beyond that. That is, no traffic would traverse the router in less than 200ms, and every other flow would be fixed at 700ms, 1200ms, 1700ms, etc amounts of latency. Tweaked correctly that would limit location to continent, unless…

One problem might be with latencies right at the boundary between two buckets. A bit of jitter would let you know you're near the edge with enough sampling. And if you can add a little latency then you can move the boundary where you like. It seems like the only way to avoid that is with one bucket (constant time).

Even if it's one bucket, isn't it still vulnerable to the same attack you describe? If you push the latency to the edge, you'd know how much is yours and how much the bucket's. Even if it was randomized you could still figure out the window of the added noise with enough sampling and you're back to where you started. I don't see a way out, other than if someone really wants to avoid these types of attacks, then using a VPN is the best bet here.

Re: Abusing WebRTC to reveal coarse location data in Signal

#42

Post by stagas »

LargoLasskhyfv wrote: post #28
gregoryl wrote: post #27

Earlier quoted context omitted.

I hope you can come back in a day or so, and re-read this conversation. You're not being very nice, or fair, and it doesn't portray you in a good light.

I probably will. It may have come across harsh, but wasn't intended as such. IMO i outlined the reasons why sufficiently in my post and edit.

Maybe you misunderstood what the tool is doing. It is not doing geoip, it is using the latency of pings between your client and some selected servers with known locations, then calculates the center based on those timings and these known locations. Very simple, you can look at the code and see what it's doing. It's not factoring in any kind of real latency, such as the speed of light, hop delays, etc. Unfortunately, as others pointed out, this method works poorly, especially in such long distances. In my tests you can only find a certain window that performs well for your location, still within a radius of hundreds or thousands of kms, which makes it pretty unusable as you point out. Knowing what _doesn't_ work is also valuable information.

Re: Abusing WebRTC to reveal coarse location data in Signal

#43

Post by stagas »

Disposition wrote: post #12
ravenstine wrote: post #3

Earlier quoted context omitted.

That's pretty interesting. So, effectively, a triangulation based on latency times?

Hate to be a pedant, but it's technically trilateration.

I didn't know this term, thank you for being such a pedant :) knowing the right term makes it easier to find information on the subject.

Re: Abusing WebRTC to reveal coarse location data in Signal

#44

Post by LargoLasskhyfv »

stagas wrote: post #42
LargoLasskhyfv wrote: post #28

Earlier quoted context omitted.

I probably will. It may have come across harsh, but wasn't intended as such. IMO i outlined the reasons why sufficiently in my post and edit.

Maybe you misunderstood what the tool is doing. It is not doing geoip, it is using the latency of pings between your client and some selected servers with known locations, then calculates the center based on those timings and these known locations. Very simple, you can look at the code and see what it's doing. It's not factoring in any kind of real latency, such as the speed of light, hop delays, etc. Unfortunately,…

I understood that. Let me replay it from my mind, how i percieved it. There is the dark map with white contours. And yellow points on it, which represent the triangualiton servers, i guess? Even clickable, at least the RED point which represents my assumed location sometimes moved. Most notably when i clicked on London, then it hopped to Odessa. Otherwise, it was mostly in the northeast region of the Black Sea. In the light of the recent IPv4-space acquisition of my ISP, which i wrote about containing addresses formerly used in the Ukraine, Russia, Irak and Iran, causing "funny" issues...what would you have thought?

Re: Abusing WebRTC to reveal coarse location data in Signal

#45

Post by LargoLasskhyfv »

LargoLasskhyfv wrote: post #44
stagas wrote: post #42

Earlier quoted context omitted.

Maybe you misunderstood what the tool is doing. It is not doing geoip, it is using the latency of pings between your client and some selected servers with known locations, then calculates the center based on those timings and these known locations. Very simple, you can look at the code and see what it's doing. It's not factoring in any kind of real latency, such as the speed of light, hop delays, etc. Unfortunately,…

I understood that. Let me replay it from my mind, how i percieved it. There is the dark map with white contours. And yellow points on it, which represent the triangualiton servers, i guess? Even clickable, at least the RED point which represents my assumed location sometimes moved. Most notably when i clicked on London, then it hopped to Odessa. Otherwise, it was mostly in the northeast region of the Black Sea. In th…

edit: btw. tested in latest Firefox with uBlock Origin on/off. and Iridium Browser (Chromium derivative), retested in Iridium only after 24h dyn-ip renewal. Same results.

Anyways, time to sleep. Sun's getting too bright.

Re: Abusing WebRTC to reveal coarse location data in Signal

#46

Post by zrm »

jrockway wrote: post #38
dannyw wrote: post #33

Earlier quoted context omitted.

This is extremely unusual to me. Personally I notice it when my ping to local game servers go from 5 to 25. I’d recommended you look into it, and potentially get another modem. If all my requests started taking another 30ms, I’d consider my network degraded.

Seems like everyone with any cable ISP has this problem. It could be a modem problem, but it's happened with a variety of modems. It could be an ISP problem, but both Comcast and Spectrum users see the same thing in my experience. I'd be interested in hearing counterexamples, but I imagine that people with good experiences are on DSL or Fiber.

I can ping 1.1.1.1 right now at 12-15ms, or Google at around 20ms, via Comcast. Less than 10ms to either one on Optimum. But it's 25-30ms to ping Optimum from Comcast.

Re: Abusing WebRTC to reveal coarse location data in Signal

#47

Post by mirimir »

cjbprime wrote: post #30
upofadown wrote: post #11

>Even Edward Snowden, the well known American Whistleblower, claims “I use Signal every day.” Well, 5 years ago...

Presumably he's been using Signal over Tor, defeating all such attacks as a side-effect.

Can one use Signal via Tor? If so, a URL would be useful.

But one can use Session (a fork of Signal) over Lokinet (an onion routing network, which is similar to Tor).

Even the updated version of Signal merely relays stuff through a proxy. That is, there's just one hop, and that's trivial to deanonymize. With Lokinet, there are multiple hops, so adversaries must compromise multiple nodes.

Also, Session requires no PII for account creation. That's great for anonymity, but there's no built-in authentication. So users must authenticate contacts in meatspace or via other communication channels.

Re: Abusing WebRTC to reveal coarse location data in Signal

#48

Post by ajconway »

mirimir wrote: post #47
cjbprime wrote: post #30

Earlier quoted context omitted.

Presumably he's been using Signal over Tor, defeating all such attacks as a side-effect.

Can one use Signal via Tor? If so, a URL would be useful. But one can use Session (a fork of Signal) over Lokinet (an onion routing network, which is similar to Tor). Even the updated version of Signal merely relays stuff through a proxy. That is, there's just one hop, and that's trivial to deanonymize. With Lokinet, there are multiple hops, so adversaries must compromise multiple nodes. Also, Session requires no PII…

Lokinet seem to claim (https://medium.com/@LokiNetwork/lokinet-b8f738fefe7a) that their network is more resistant to sybil attacks by introducing different incentives (an internal cryptocurrency) and not having a central authority (which TOR does have, and which users have to trust). It's unclear how this helps against a wealthy adversary determined to control the network via its own nodes.
Post reply on HN