"Near a user" is also a big assumption. I'm ~200 miles to ORD and ~500 to IAD, but my ISP's peering & upstream arrangements mean Cloudflare serves my traffic 700 miles from DFW.
But, at the same time: Cloudflare isn't going to serve me a cache from Seattle, Manchester, or Tokyo. Pinning down an unknown Signal user to even a rough geographic location is an important bit of metadata that could combine to unmask an individual. Neat attack!
It's also quite insidious as you don't need to control anything on any server to get this information; as long as you can get your target to load a unique URL never before loaded by anyone else, you can simply later poll it with an unauthenticated HTTP GET from different locations, and find which one reports a Cloudflare HIT (or, even if they hid that information, finding the one that returns with lower latency).
If you're allowing user uploaded content, and you use Cloudflare as a CDN, you could mitigate and provide your users with plausible deniability by prefetching each uploaded URL from random data centers. But, of course, that's going to make your Cloudflare bill that much more expensive.
Cloudflare could allow security-sensitive clients to hide the cache-hit header and add randomized latency upon a cache hit, but the latter protection would also be expensive in how many connections must be kept alive longer than they otherwise would. Don't do anything on a personal device or account if you want your datacenter to be hidden!
Pre-fetching also becomes an issue for apps that are meant to be e2e encrypted, since it requires the server to download (read) every attachment. But if the app is already caching the attachment then they’re effectively reading it anyway.
(EDIT: Apparently signal e2e encrypts images prior to upload, so pre-fetching the encrypted blob from one or multiple servers would in fact be a mitigation of this attack.)
I do wonder if Telegram is as invulnerable as the author assumes. They might not be using Cloudflare for caching, or even HTTP, but the basic elements of this attack might still work. You’d just need to modify the “teleport” aspect of it.
Telegram doesn't use local CDNs for caching. All users are associated with one of about five telegram DCs, and upload files to their local DC. If a file was uploaded by a user on another DC, users connect to it temporarily to download the file.
The DC that a user is associated with is exposed by the API - you don't need to get them to upload a file to discover it - but it's so broad that it's not much of a deanonymizing signal. (Knowing that your target is in DC1, for example, just means that they're probably somewhere in North or South America. Or that they registered using a phone number that said they were.)
> Going forward uploaded content should never go through cloudflaire and it never really needed to.
The problem in this case isn't cloudflare. The problem is that these images load without the user's interaction and the person sending it gets to choose if it's cloudflare or not. So your statement within this context doesn't really work.
The person receiving it chooses to download images or whatever automatically though.
I dunno, I'd still say the problem is at least 50% cloudflare. Why should they make which datacenters have a resource cached be obvious public knowledge? I do agree though, one could still end up inferring this information noisily by sending an attachment, waiting a while, and then somehow querying a lot of DCs and trying to infer times to see if it's cached or not.
Personally, I've never been a fan about so many things like URLs being so public. I get the benefits of things like CDNs and what not and the odds of guessing a snowflake value and what not, but still...all attachments in Discord are public. If you have a URL, you have the attachment. And they're not the only ones with this kind of access model.
Isn’t that because the URL parameters are so long that by design they effectively _are_ the password protection for the resource ? They shouldn’t be able to ‘leak’ to unintended recipients.
Personally, like you I’m also not a huge fan of this, but URLs like that basically should be treated as the passwords. Don’t post them publicly / don’t give them out to people you don’t trust.
There's a part of me that's fine with it for a short-lived URL which contains a temporary access key but for a forever URL with a forever access key I'm not entirely happy with it.
I use it to share memes and shitpost but definitely not something to share sensitive content IMO.
For signal then the issue becomes saving who owns what image (so that you can re-issue “passwords”) and THAT is much more dangerous to the users than simply allowing users to grab semi-anonymous links into their cdn with enough of a url to be nearly impossible to iterate through every combination without hitting tons of rate limits. (Ignoring this location cache timing issue.)
Edit: Actually... (in signal's case) it might be possible to provide the user's device 2 tokens, 1 to access the url and 1 to issue new access links. Then the user can request a new access link with their second token when their url access token expires. Signatures would help prevent it from needing to be stored in the database. It would be interesting to try.
Edit2: Also I am now curious... does this mean only text messages are e2ee? yikes.
My main gripe is that if someone finds a vulnerability that gives you a list of urls the model falls apart. I’ve seen this happen in organisations :/
But agree with your statement here and others about the lifetime of the data - if something is sensitive or secret you want proper access controls applied, not just openssl rand -hex 8
Note that CF will also route relative to the sites' plan. Enterprise sites are almost always routed to the closest DC, while if that DC is overloaded then lower tier websites, typically just Free sites, will get routed elsewhere (I suppose this is achieved via different anycast ranges where a specific DC is excluded). Although Discord, Signal, etc are almost certainly Enterprise sites.
I doubt how useful it would be as an attack. As a single point of info it tells you next to nothing. As part of a composition of other indicators it would be the weak link in the chain probably just causing noise for the not un-likly scenario where the person you're targeting is using a VPN.
If it was any less specific we'd be talking about a deanonymization attack that outs whether or not a target is still on Earth.
Oh, this attack would be a useful tool for e.g., identifying whistleblowers that travel a lot (e.g., in academia, military). If you know their Signal ID, you could send them images from time to time and then compare their coarse locations with travel information for a number of suspects.
I believe they'd have to accept the chat request before any images would be loaded?
Looking at the app options it seems to be possible to disable media auto-download entirely; there's tickboxes for Images/Audio/Video/Documents via Mobile Data/Wi-Fi/Roaming.
Yes, I agree. This attack won't work on competent / paranoid people. What I had in mind when writing the comment: a whistleblower who wants to inform the press about illegal practices in their company and installed Signal to communicate anonymously with journalists. Somehow, a detective working for the company got their Signal ID and contacted them, impersonating a journalist.
> 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.
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.
I disagree, it does significantly increase the likeliness. Like having cancer makes you significantly more likely to know a lot of medical facts about cancer.
If you fear for your life you are much more likely to have spent time researching how to protect yourself digitally.
There's a lot of nonsense too. In another HN thread, someone was explaining to me that email is more secure than Signal, and desktops more secure than phones - and they had a link to someone's blog to prove it.
That's a HN reader. For the non-technical, it is a minefield.
for "normal people", that's a pain, but with enough resources,...
Although. it has edge usecases even for "normal people":
Eg. you suspect your coworker to be catfishing you on eg. discord, you know that he's in your city now, verify, then wait for him to leave for a vacation to somewhere abroad, check again.
This is actually pretty smart, and shows that this exploit could be chained with other information to identify a specific individual. This could also be used to e.g. check which world-travelling reporter is communicating with you.
It's not an edge case. Using multiple sources of information to paint a more complete picture is the norm. That's how marketing profiles work, for example.
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.
But, at the same time: Cloudflare isn't going to serve me a cache from Seattle, Manchester, or Tokyo. Pinning down an unknown Signal user to even a rough geographic location is an important bit of metadata that could combine to unmask an individual. Neat attack!