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

0-click deanonymization attack targeting Signal, Discord, other platforms

gist.github.com

Post reply on HN
Print view View original

371–380 of 474 posts

Re: 0-click deanonymization attack targeting Signal, Discord, other platforms

#371

Post by autoexec »

crtasm wrote: post #364
autoexec wrote: post #313

Earlier quoted context omitted.

I highly doubt that signal does anything to help with mass surveillance. Signal started keeping people's name, photo, phone number, and contacts in the cloud protected by a "secure" enclave the NSA almost certainly has access to and hackers already got into ( https://community.signalusers.org/t/sgx-cacheout-sgaxe-attac... ) and even leaving all that aside, all anyone needs is a PIN that can be trivially brute forced.…

I thought it was digits only but see there's always been the option to use an alphanumeric passphrase as the "PIN". That prevents brute-forcing for anyone that bothered to use one, right?

It was only digits initially (https://old.reddit.com/r/signal/comments/oc6ow4/so_a_four_di...), with nothing preventing very easy ones like "1234", but even after they fixed it they continued to call it a PIN and many people would just assume is a number ("number" is right in the acronym), and often a very short one. Most people didn't want to set a PIN at all, they'd been being nagged about setting one and then got nagged again and again to reenter it.

It was not clear to most people that their highly sensitive info was being uploaded to the cloud at all let alone that it was only protected by the PIN. I wouldn't be surprised if a lot of people picked something as simple as possible.

https://old.reddit.com/r/signal/comments/gqc2hu/the_new_pin_...

Re: 0-click deanonymization attack targeting Signal, Discord, other platforms

#372

Post by Aachen »

HeatrayEnjoyer wrote: post #239
udev4096 wrote: post #188

Earlier quoted context omitted.

If you aren't comfortable broadcasting it, then maybe take measures so that it doesn't get to that point. Privacy is not by default, ever

Privacy by default is Signal's entire brand

Weather predictions are the weather channel's entire brand, but people understand the concept well enough to know that this doesn't mean it's infallible. There is a limit to how many warning stickers we need in the world. If you want to rely on a particular feature, maybe check that the product supports said feature. Signal does encryption, not onion routing

Re: 0-click deanonymization attack targeting Signal, Discord, other platforms

#374

Post by shakna »

wkat4242 wrote: post #350
shakna wrote: post #346

Earlier quoted context omitted.

Cloudflare does serve me from France. When I'm in Australia. (My ISP bought some IP addresses that were original regional France, back in the early 90s.) So though this does have implications, the assumptions they utilise, like always, are not universal.

Wow doesn't that make things really slow due to the RTT of the acknowledgements?

Australia. Our fastest networks are pathetically slow.

The L2 FTTN parts of the NBN have been known to have an RTT in the range of minutes, for some locations.

My own varies from 5ms, for those who don't assume my geography, out to 890ms for those that do.

Re: 0-click deanonymization attack targeting Signal, Discord, other platforms

#375

Post by kijin »

chatmasta wrote: post #167
kijin wrote: post #71

Earlier quoted context omitted.

AFAIK the attack described by OP only works if the attacker knows the (randomly generated) URL of the image, which probably means they have a Signal client that can decrypt the image already. So the secrecy of the content is not at issue. The question is whether some specific person has received the same image, and from where.

Part of his attack requires disabling the cache on his (sender) side so that he doesn’t pollute the cache. That implies that both sides of the conversation share the same URL, which means Cloudflare could assume two IP addresses requesting the same URL on the Signal attachment domain are participating in a shared conversation.

Yeah, that's a problem. It is leaking metadata, not content.

Ideally, the image should be padded, encrypted with a different key, and given a different URL for each user who is authorized to view it. But this would increase the client's burden significantly, especially in conversations that include more than two people.

Re: 0-click deanonymization attack targeting Signal, Discord, other platforms

#376

Post by Aachen »

honestSysAdmin wrote: post #243

I guess I'm not so "crazy" for funneling all my Android's outbound traffic through a VPN that does two hops.

Whether that's crazy depends on your threat model. If there's no reason, it could still be crazy in the sense of protecting from an irrational fear. If you communicate with people or organisations who shouldn't know your location, it makes sense. It depends

Re: 0-click deanonymization attack targeting Signal, Discord, other platforms

#377

Post by crtasm »

autoexec wrote: post #371
crtasm wrote: post #364

Earlier quoted context omitted.

I thought it was digits only but see there's always been the option to use an alphanumeric passphrase as the "PIN". That prevents brute-forcing for anyone that bothered to use one, right?

It was only digits initially ( https://old.reddit.com/r/signal/comments/oc6ow4/so_a_four_di... ), with nothing preventing very easy ones like "1234", but even after they fixed it they continued to call it a PIN and many people would just assume is a number ("number" is right in the acronym), and often a very short one. Most people didn't want to set a PIN at all, they'd been being nagged about setting one and then go…

Their announcement post says "at least 4 digits, but they can also be longer or alphanumeric", though maybe the feature had launched before that was written? https://signal.org/blog/signal-pins/

Far from ideal I agree.

Re: 0-click deanonymization attack targeting Signal, Discord, other platforms

#378

Post by Aachen »

Einenlum wrote: post #218

I guess one possible fix would be for cloudflare to implement an option to disable the x-cache header for unauthorised users. This way Signal devs could still check their setup by sending authentication headers. But it would solve the issue completely because you could always check the response time. Probably Signal should disable caching. I guess it's rare for someone to repeatedly download an attachment. Once it's…

Not sure it's so rare. A large number of group chats will have people in the same area. For me it's the vast majority: family chat, groups of old classmates or flatmates are mostly in the same country, work chats too... I can think of one exception where a group member will consistently be hitting a different Cloudflare node from everyone else, but for everyone else, every time I send a picture into a group chat the caching will save traffic

Re: 0-click deanonymization attack targeting Signal, Discord, other platforms

#380

Post by mmooss »

kdmtctl wrote: post #297
mmooss wrote: post #252

Earlier quoted context omitted.

> not un-likly scenario where the person you're targeting is using a VPN Do you think a large proportion of Signal users also use VPNs? I'd expect it would be a higher proportion than the general population but still only a small minority.

> Do you think a large proportion of Signal users also use VPNs? It is feasible to consider that interesting Signal users mostly use VPN as an extra protection layer.

Being 'interesting' doesn't make you more likely to understand VPNs and opsec. I expect it makes you more likely to try, but there's a good chance of doing it ineffectively.
Post reply on HN