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

21–30 of 64 posts

Re: Abusing WebRTC to reveal coarse location data in Signal

#21

Post by mike_d »

upofadown wrote: post #11

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

Edward Snowden has a vastly different risk profile than anyone else.

It it without a doubt that he is under constant electronic and physical surveillance by the Russian and American governments. His phones and computers are also very likely compromised. At that point your choice of messenger app matters about as much as the color of your socks because the interception is happening at another layer.

Re: Abusing WebRTC to reveal coarse location data in Signal

#22

Post by andrewstuart2 »

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…

I find that interesting, because you could probably classify physical location revelation attacks with other timing-based attacks for which we've had to resort to constant-time algorithms (e.g. key protection via constant-time cryptographic operations).

There's an interesting fundamental tradeoff somewhere between optimization and information. If you make things as efficient as possible, you'll probably leak information.

Re: Abusing WebRTC to reveal coarse location data in Signal

#23

Post by stagas »

ummonk wrote: post #18
stagas wrote: post #4

Earlier quoted context omitted.

That's funny, I was just working on a POC like this today[0] - it's accurate most of the time for my location but I haven't tested from other locations. You'd need to tweak the 'known' servers on and off to find the optimal arrangement because you'd need to be somehow inside the polygon. I was planning to find a way to discover these itself and other tweaks (like trying multiple times then averaging out) Edit: the pa…

Weird. Your POC seems to be placing me almost directly opposite in the caucasus.

Yeah, it doesn't work really well :) Work in progress

Re: Abusing WebRTC to reveal coarse location data in Signal

#24

Post by controlweather »

I was once fired from a telecom company in SF for finding that webrtc twilio packets all went through China who was taking a copy and routing back. I investigated because customers complained of heavy delays in their voip. So yeah that was like 7 years ago.

Re: Abusing WebRTC to reveal coarse location data in Signal

#25

Post by billme »

pthatcherg wrote: post #15
kodablah wrote: post #10

I can see where a FQDN candidate is no biggie in a browser's offer/answer since DNS lookups occur all the time. But I imagine the simple fix for Signal's WebRTC use, since they control both sides of the exchange, is to just disregard non-IP candidates. Or even better, don't do anything with the candidates until the call is accepted. Worst case, could just have a geographically centralized signaling server (or shared…

Disregarding non-IP candidates is exactly what we've chosen to do (and which the new versions of the app do). The downside of disregarding all candidates until the call is accepted is that post-accept connectivity would be much slower. Going through a server to hide your IP is an option in the settings in the app, but it can potentially lead to higher call latency, so there is a trade-off. To prevent issues like this…

>> “ PINs will also help facilitate new features like addressing that isn’t based exclusively on phone numbers, since the system address book will no longer be a viable way to maintain your network of contacts.” [1]

Any idea when more information might be available on this? Asked moxie years ago to add this and know 100s of other have too.

Worth noting the FAQ as it relates to the PIN length is not correct, “How long can my PIN be? There is no limit. Feel free to add as many characters as you want.” [2] ...tested it and longest PIN I was able to create was 20 characters all numeric.

[1]: https://signal.org/blog/signal-pins/

[2] https://support.signal.org/hc/en-us/articles/360007059792-Si...

Re: Abusing WebRTC to reveal coarse location data in Signal

#26

Post by jerrysievert »

andrewstuart2 wrote: post #22
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…

I find that interesting, because you could probably classify physical location revelation attacks with other timing-based attacks for which we've had to resort to constant-time algorithms (e.g. key protection via constant-time cryptographic operations). There's an interesting fundamental tradeoff somewhere between optimization and information. If you make things as efficient as possible, you'll probably leak informat…

> If you make things as efficient as possible, you'll probably leak information.

at which point the threshold could lower ...

Re: Abusing WebRTC to reveal coarse location data in Signal

#27

Post by gregoryl »

LargoLasskhyfv wrote: post #16
stagas wrote: post #14

Earlier quoted context omitted.

I mentioned I just started working on it. To try for yourself you'd need to clone and tweak the servers list to find an optimal arrangement for you. The problem as I see it is that jumping continents occurs really artificial delays which skews the result significantly, so it first needs to identify your relative whereabouts, then decide on an optimal set of servers. If you clone and tweak the servers to place yoursel…

At least they are current ;-)

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.

Re: Abusing WebRTC to reveal coarse location data in Signal

#28

Post by LargoLasskhyfv »

gregoryl wrote: post #27
LargoLasskhyfv wrote: post #16

Earlier quoted context omitted.

At least they are current ;-)

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.

Re: Abusing WebRTC to reveal coarse location data in Signal

#29

Post by skybrian »

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).

Post reply on HN