There's a "Signal deanonymized" thing going around:
https://gist.github.com/hackermondev/45a3cdfa52246f1d1201c1e8cdef6117
Stay calm. Deep breaths.
In other words, it's not great that this is possible, but nowhere near an immediate and present danger to anyone except a very very small group of people doing very very specific things.
If you're in that group, you'd already known you are. You'd have someone to ask about this. And you'd almost certainly be using some other tools to anonymize yourself anyway.
If that's not the case, then this is almost certainly not something to lose sleep over. Signal remains a safe choice of a secure IM.
If you are still worried about this, my read of it is that these things might make the attack more difficult:
This makes this attack rely on you clicking the image to download it, making it very difficult for the attacker to know when to check for the cached status of the resource.
This is important, because for each attachment the attacker can only ask this question once per the period Cloudflare caches these resources (not sure exactly).
You can also:
Technical details tl;dr:
- Signal (and other communication platforms) uses Cloudflare with caching enabled for media
- one can check on which Cloudflare endpoints a given attachment URL got cached (one can use a VPN for this), giving them the ability to roughly geolocate users whose Signal downloaded the file
- a doctored version of Signal (or whatever app) allows the attacker to send the message with an image, and extract the attachment URL to know what URL to check for having been cached
- images usually get downloaded automatically (and thus get cached on Cloudflare side)
- push notifications make this a 0-click thing, as the targeted user doesn't even have to click on a conversation to have the image downloaded
I believe this technique would work against any communication app that uses any global CDN that does endpoint caching and provides the caching status in HTTP headers of the response.
I'd like to hear what @signalapp has to say about all this. There is a claimed response from Signal in that gist file, but I'd like to see it come directly from Signal before I form an opinion.
@rysiek *yet another reason why I think @signalapp is just a successor to #CryptoAG aka. #M'INERVA / #RUBIKON...
#CryptoLeaks 2.0 - when?
@kkarhan I think spreading this kind of conspiracy crap is actively harmful to a lot of people. I'd like you to never do that again in my replies, thanks.
@rysiek How much do you bet it's true?
Feel free to ignore the #InconvenientTruth...
Didn't they already give a responding statement? That's what 404Media are reporting.
I'd like to see a public statement from @signalapp too. Too many people ate this clickbait already, and they start being annoying.
Otoh, why would one need a caching CDN for one time delivery of an encrypted payload? #signalapp is a private messaging app, not a content broadcasting tool. Or is it?
@rysiek @signalapp excellent analysis. Fully agree that this attack doesn't match the average user's threat model and great suggestion that the probe can be eliminated by disabling read notifications. I would add that this is more of a Cloudflare bug. They should fix this.
@freddy @signalapp I tend to agree, but I would expect Signal to push on them to fix this.
And by "fix this" I mean "stop broadcasting cache status and POP site location in HTTP response headers all the time".
@rysiek Which is why my expectation until now was that they just simply don't outsource that. And if they did, that they made sure that it passes a basic laugh-test. But to use clownflare? And declare it to be out of scope because it is "up to users to hide their identity" (from a company that hard-verifies your phone number no less!) wtaf. But eh... one trust-us-pinkie-promise-company hand in hand with another pinkie-promise-company.
Very entertaining, from an outside perspective
@rysiek@mstdn.social CDNs confirmed once more to be a liability if anything. Stop using garbage like Cloudflare, stuff like this keeps happening. Its a shame that Signal uses it and doesn't see an issue.
@rysiek this would work even without the cache status in the response.
you can infer the status from latency observations.
I'll also note that apps don't have to use CDNs for images and thus could get REALLY, REALLY specific information about your location. The fact that CDNs are prevalent is a privacy feature.
Of course, any app on your device of choice could report all sorts of information about your device and you. Use a web version when you can. They're not perfect, by any stretch, but it requires more effort and devs are lazy.
@rysiek Thank you for this summary.
BTW, does using a trusted proxy in Signal help to mitigate this issue?
@agturcz I am not sure, I don't know enough about trusted proxies.
@rysiek You can set a proxy to be used by Signal. I would expect that in this case request to download the attachment from CDN goes through the proxy. And the best the attacker will get is the ip address of the proxy.
However, I will reveal my ip to the proxy. That's why trusted.
@agturcz yeah, that would make sense to me
@agturcz @rysiek Use @torproject or better yet, #XMPP+#OMEMO with an #OnionService aka. #Server on a .onion
domain...
@kkarhan I ran and hosted a bunch of XMPP servers a while back. It was a pain to use, and it was easy for users to make mistakes and accidentally send messages in the clear.
You are making people les safe. Last time: please stop doing this in my mentions and replies.
@rysiek @agturcz that's not how you fix #TechIlliteracy, espechally since things changed for the better.
@monocles / #monoclesChat & @gajim / #gajim are quite easy, whereas @signalapp / #Signal demands #PII in the form of a #Phone number which is more often than not not legally obtainable without "#KYC" aka. "forced #SelfDoxxing" all whilst being an extremely #centralized, #SingleVendor & #SingleProvider solution that falls under #CloudAct ant thus cannot adhere to #GDPR & #BDSG!
"JuSt UsE sIgNaL !"
won't fix #TechIlliteracy but rather provide false sense of security to #TechIlliterates when the correct solution is to teach proper #TechLiteracy like @cryptoparty@chaos.social / @cryptoparty@mastodon.earth / #CryptoParty does...Otherwise we'd only perpetuate the #Enshittification-#Lifecycle as has happened with #AIM, #ICQ, #BBM and so many more...
If #Signal and @Mer__edith actually cared, they would've setup their system truly decentralized as an #OnionService over @torproject / #Tor!
@rysiek I'll give you a week to #TouchGrass and come back...
@kkarhan Sorry but no, the correct solution is to push for easy to use solutions that are at the same time private and secure. Hiding privacy and security behind a veil of "you need to know" is discrimination of people that are not able (either mentally, physically or monetary) to gain that knowledge.
The correct move here is for @signalapp and any other service to fix this and for legislators to enact laws enforcing proper security and privacy by design.
"[...] easy to use solutions that are at the same time private and secure. [...]"
It is easier, faster, cheaper and overall simpler to get someone setup with #XMPP + #OMEMO espechally if they don't have a #PhoneNumber and/or #ID to acquire a #SIM.
And if you go and say, "Just buy a [insert country here] [e]SIM!" and expect #TechIlliterates without a #CreditCard, #PayPal or other means of #OnlinePayment to fiddle around with some #eSIM if not having to get some #eSIMcard because they can only afford to maintain one SIM and can't spend triple-digits on a new devices then you completely missed the point!
It's not that I expect anyone to get #TechLiterate within minutes, but similar to setting up a cordless DECT phone it's something one has to do once in 5 years and just have them put the password in a safe spot to retain...
Point is that #Signal #WontFix their setup and that was evidently clear even before @Mer__edith succeeded #MoxieMarlinspike: Their entire operation has a distinct #CryptoAG stench as it's an #unsustainable #VCmoneyBurning party!
A counterexample on how this could've been done are #Tor, #eMail and other truly #OpenSource as in #MultiVendor & #MultiProvider standards.
NOTHING compells Signal to demand PII, run a #Shitcoin #Scam aka. #MobileCoin that even seasoned #TechLiterates and #CryptoBros can't setup properly, and in fact Signal using phone numbers makes it trivial to discriminate against users and easier for them to identify them!
If my reasoning didn't resonate with you, then try helping i.e. undocumented migrants aka. "#SansPapier|s" to get setup with it without violating laws and/or ToS and/or needing an imported SIM which I'm shure most folks don't have on hand!
Whereas it's trivial to get people setup on one of many XMPP servers I've personally tested!
AFAIK Signal doesn't even have an #OnionService / .onion
for their Website, much less any #API enpoints to use it with!
You're free to also provide evidence and supporting data to your arguments, rather then neighsaying against proven to be more secure and reliable [by virtue of decentralization] options like XMPP+OMEMO and/or #PGP/MIME.
The proper fix is to actually assess the situation and acknowledge the risks and limitations as well as the very nature of communications, which means upgrading later is exponentially more painful, thus getting people properly setup once is way easier.
Speaking of #monocles: That business is at least #sustainable because it's funded by users (€2 p.m.) which they can pay anonymously
I sent my grandma the app store link for @signal and she was able to install it and communicate with the family without having to guide her through anything. They've really made it that simple. I wouldn't be able to do that with any other app.
@max @kkarhan please point me at a system with a better ratio of security gained to effort spent than @signalapp ? Bonus points if it's actually used by people.
No problem:
I could go on all night, so please shove that #TechPopulism somewhere the sun doesn't shine!
@rysiek @kkarhan @agturcz An awful lot of people say they've used #XMPP "a while back". But they're often unaware of the best of XMPP, and have an unfairly negative view of it.
Did you happen to try...
...#Snikket for hosting?
https://snikket.org
...apps like #Quicksy and #Prav which use phone numbers for easy onboarding, same as #Signal #WhatsApp or #Telegram?
https://quicksy.im
https://prav.app
...featureful clients like #Cheogram #MonoclesChat #Gajim #Movim etc?
@contrapunctus @agturcz yes, I am aware of all these. I am also aware of Simplex, Briar, and whole slew of completely decentralized IMs. And I made a long ranty talk about shortcomings of Signal that one time, got pretty popular on media.ccc.de.
And I still react badly to unnecessarily alarmist hot takes that can lead regular folks to make bad technological decisions.
@rysiek @agturcz Then, I confess to being confused about what you mean.
Why did you find it to be "a pain to use"?
Some clients don't have end-to-end encryption enabled by default - I hope that will change some day, but I never found that to be a dealbreaker. If someone sends cleartext, me and my friends immediately ask them to enable OMEMO.
Still, no feature or convenience is worth using a centralized silo. Reddit, Twitter, and Meta are proof enough.
@contrapunctus @agturcz first of all, please don't explain centralization to me, I was talking about it before it was cool:
https://media.ccc.de/v/30C3_-_5319_-_en_-_saal_g_-_201312282330_-_technomonopolies_-_rysiek
Secondly, "some clients don't support X" is a deal breaker. Because now regular folks need to track and think about whether or not their contact's server supports a safety feature they rely on.
Third, "if someone sends a cleartext…" is not anywhere near being acceptable for a communication tool like that. Sending cleartext should not be *possible*.
@contrapunctus @agturcz I had worked with people reporting on Panama Papers, I had worked with people working with sources whose threat model included men with guns who were trained and willing to use them.
This kind of "no biggie if someone sends cleartext, we can ask them to enable OMEMO" stuff is what can get people killed. Advocating for tools like that is putting real people in real danger.
I am glad XMPP is improving, but it is simply nowhere near a Signal replacement yet.
@rysiek @agturcz Sounds like @snikket_im is your best bet, then. All Snikket clients have OMEMO enabled by default. And this way you actually can actually trust the operator, i.e. yourself, and control exactly what cloud services are used (including "none").
And Signal is seemingly not the perfect solution it's being made out to be, either.
@contrapunctus you seem to be ignoring what I and others are telling you about how dangerous what you're doing – promoting XMPP into a space it has no business being in in its current state – is.
I am done with this conversation.
@rysiek @contrapunctus @agturcz @snikket_im I still have to disagree that Signal is better than XMPP in general. Signal has these terrible qualities of using a phone number for registration and being a centralized service. It's also not (afaik) really free software, and they might not be telling us everything. I do think it's nice that Signal proxies cleverly hide traffic using HTTPS. Ultimately XMPP is the wiser choice, and who sends messages in plaintext? All traffic to the server is encrypted with TLS.
@rysiek @contrapunctus @agturcz @snikket_im In any case, whether it's Signal, XMPP, or Delta Chat, you would have to take some configuration steps to hide the fact that you are using them. Delta Chat is pretty easy to hide and sneak through firewalls because e-mail is generally treated as innocuous. Choosing the right server with Delta Chat probably your safest route.
@rysiek @contrapunctus @agturcz yes, this! I gave up on XMPP for this exact reason. The chain of
- my app supports it
- my server supports it
- their server supports it
- their app supports it
is simply ridiculous. I have used XMPP when we had nothing better. Now we have. Time to move on.
@claudius @rysiek @agturcz You'll face it with every open standard - email, IRC, ActivityPub (!!), Matrix...but somehow, only XMPP gets singled out as "unusable" (even though plenty of people - like me - use it without any issues.)
It's a bloody stupid excuse to use a centralized system for the whole world's communication, and you'll never convince me otherwise.
Have fun silo-hopping. The sane people will be on XMPP as they've always been, pointing and laughing at the silo-lovers.
@contrapunctus @rysiek @agturcz the XEP process is simply broken and clients don't keep up. I did not have nearly as many problems with any of the things you listed. Yes, email is a horribly old protocol that is held together by spit and duct tape, but at least it does not get in my way. XMPP never worked frictionless for me. And, yes, I really tried. And, no, I am not stupid.
@contrapunctus @rysiek @agturcz unfortunately "but which OMEMO" is a thing, and most clients use the old, less secure version, while "we don't care about those bugs, there's a new version that's much better" is used by next to no clients
https://soatok.blog/2024/08/04/against-xmppomemo/
@viq @rysiek @agturcz Let's not post FUD?
Here's a response to it.
https://www.moparisthebest.com/against-silos-signal/
OMEMO author Tim Henke also made this fairly civil comment on the post, which was - somewhat surprisingly - deleted by Soatok. https://www.moparisthebest.com/tim-henkes-omemo-response.txt
@agturcz
...or - as suggested above - use Tor which is effectively a trustless proxy (HTTP/Socks proxying) which only reveals irrelevant exit-IPs. For example on Android under Orbot's settings (for apps to auto-tunnel traffic for) Signal is grouped under "recommended". If having problems connecting to Tor directly you can either enable connect-plugins like obfs4, Snowflake, or some other bridge, or connect to Tor over a VPN or SSH tunnel (optionally run on your own cloud VM).
@rysiek oh yikes
you're right that it's pretty niche threat model where this matters, but wow that's a devious side channel
@Gaelan devious indeed.
@rysiek but why are these cloudflare cache headers even there?
@stefan because if you are a website owner and trying to debug a problem, you need them.
This *could* be done better though. Turn it on for debugging, turn of afterwards, for example.
@rysiek Any info if using a Signal proxy mitigates this, or is this specifically a client-level thing? Assuming the latter.
@rombat I am not 100% sure how trusted proxies work in Signal, but basically: it's about the location that the requests is seen by Cloudflare's infrastructure from.
If the proxy moves that somewhere else, it can help.
@rysiek I think the proxy is more about bypassing places that block Signal for client-to-server connectivity, so I'm thinking it probably doesn't apply here.
@rombat@sfba.social @rysiek@mstdn.social
Is that "trusted proxy" the same things Signal mentioned as "proxy" when Iran blocked Signal? If so, this maybe helpful, as that's essentially a TLS proxy that reroute Signal traffic from a NGINX server, so the IP address downloading media files would be from that proxy server instead of the user.
https://github.com/signalapp/Signal-TLS-Proxy
@rombat@sfba.social @rysiek@mstdn.social
It is, but it relies on client fetching resources from CDN using its ISP IP address, so if the proxy does route all traffic from client to CDN the attack should result in your proxy location's nearest Cloudflare PoP being recorded, instead of where the client actually is.
I have not tried it, though. So I can't be sure about it. Maybe you can use your proxy to fetch a picture and see where it went?
@rysiek@mstdn.social Since China blocked Signal and many other services long ago, I'm already 24/7 on a "VPN" (traffic obfuscation proxy, to be precise) before I can use Signal (or this fedi instance).
sigh