> From 2019 to 2021, Ricochet was used by the admins (as well as an undercover investigator) of the child porn onion site Boystown. To identify the perpetrators, German police used a correlation analysis attack. By sending Ricochet messages to perpetrators and monitoring several hundred Tor nodes for simultaneous traffic of the correct size, authorities were able to identify intermediate Tor nodes and then also the perpetrator's entry nodes, revealing the perpetrators' IP addresses.
>It is still unclear from where, but the investigators apparently knew that the suspect was using O2 as his internet provider. They therefore chose a different approach: based on the correlation analysis of the middle node, they had already found out the IP address of the entry guard – and could hope that the suspect would continue to use it in the coming days and weeks. So the next time the suspect was online in Ricochet, all they had to do was ask Teleofnica for the addresses of all the O2 customers who were currently connected to this very Entry Guard. The result should have been a fairly short list.
Great example of why Tor should not be forbidden: helps anonymity a lot, yet with enough "proof of work," law enforcement can still track down severe crimes. Kudos to law enforcement on this one.
Hi, morganava here. I'm currently the maintainer of Ricochet-Refresh (https://github.com/blueprint-freespeech/ricochet-refresh) which is the maintained fork of Ricochet-IM (which no longer works since like 2021 due to v2 onion-service deprecation in the tor network itself).
First the good(?) news in bulleted list format:
- As far as we know these efforts took place before the vanguards-lite feature became standard in tor which makes guard discovery of onion-services harder
- The de-anonyimsation efforts took many months if not years and was a targeted effort (i.e. they did not have a turn-key de-anonymise onion-services solution)
- it was only possible because the Germans knew the target's id/onion-service; if the target had kept their id secret then the Germans wouldn't have been able to de-anonymise it.
- we've been working on a solution to the cyber-stalking problem for a few years since it was first discovered; you can find out all about that here: https://gosling.technology/design-doc.xhtml
- work has started on the next major version of Ricochet-Refresh which will include these improvements, so look forward to that in the coming years
---
The linked bug is related but it's not exactly the attack vector believed to be used in the boystown incident. Specifically (according to this artikel linked from wikipedia: https://www.heise.de/en/news/Boystown-investigations-Catchin...), the German police seem to been able to send arbitrary messages to the target which would imply they had compromised one of the target's contacts or the target had accepted a friend request from the police. So in some sense, the Germans had an easier time at it than we hypothesized since they didn't need to rely solely on metadata of online/offline status to find the user's guard. Instead they basically got lucky and were able to fingerprint their own network traffic to the user through relays they happened to control (unknown if they ran their own custom relays or tapped existing).
Sorry it's a bit of hand-wavey here as the reporter refused to give us source documents so we don't actually know precisely how this attack worked and have had to piece things together based on their claims and the state of tor, the tor network, and ricochet-im back then. We've had to basically rely on the word of reporters that they're understanding their material correctly and that they've communicated it correctly (so like a second-hand retelling of a bug report XD). We do know it took the Germans quite a while (i.e. months to years) to do this and had to start over a few times when the target's guard node rotated.
The fundamental problem which makes this sort of attack possible is that onion-service based peer-to-peer communications necessarily require an always-on onion-service for your peers to connect to. Without this piece nothing works. To work around this problem, we've been working on Gosling ( https://github.com/blueprint-freespeech/gosling ) which at a high level, allows you to have the p2p properties without the always on possibly public onion-service by basically negotiating credentials for 'secret' onion-services known only to your authorised peers (i.e. you contacts). Once you've added all your peers/friends that you want, you can shut down the public onion-service without interrupting normal communications with your peers. This of course does imply that you need to trust you contacts aren't cops.
> This of course does imply that you need to trust you contacts aren't cops.
What happens if you find it out after the fact? Just regenerate everything and re-add friends? How much would it compromise though to have a friend that turns out to be a cop?
It does not, but work is happening in a (currently local) alpha branch on this. Unfortunately it is not a simple task and is more akin to a complete re-write in scope.
> What happens if you find it out after the fact? Just regenerate everything and re-add friends?
Currently your only recourse is to stop using your compromised id, create a new one, and re-add all your trusted contacts.
> How much would it compromise though to have a friend that turns out to be a cop?
It depends. Are you the kind of target with actual intelligence agencies interested in unmasking you?
We presume that similar finger-printing attacks are still possible but harder than they were in 2020 due to upstream changes in tor and the tor network. However, in principle cyber-stalking and the power to somehow own (i.e. run your own, hack, tap, subpoena, etc) guard nodes (and luck so that your target goes through these guard nodes) are all you need to do guard discovery. And once one knows the target's guard, you 'just' need to figure out who the guard is talking to and from there the target can be de-anonyimised.
If you find out one of your contacts is malicious and you cut off their access then you're 'fine' going forward presuming they didn't already compromise you. They would essentially have to completely start over (i.e. discover your new identity, get you to add them as a friend, wait for you to go through a friendly guard node, etc).
--
One thing that is important to bring in perspective here is that it is not easy to do this and it does take significant resources/attention to do. It takes luck, time, and particular positioning in/around the tor network (e.g. running malicious relays, dragnet surveillance, etc). The lesson to take here isn't 'oh shit ricochet/tor/whatever is broken use something else instead'.
These types of events get a lot of media attention and focus on the failures without anyone pointing out 'hey yeah everything else is non-anonymous by default'. If the target had been using AIM or something this wouldn't show up on anyone's radar because of course that shit is broken (how many times now has leakers of military secrets on Discord been identified and prosecuted?).
For the majority of users that don't have a line item in the NSA's budget dedicated to hunting them down, Ricochet-Refresh and tor in general are fine and will keep you anonymous (presuming you don't dox yourself XD). And, even if the feds are out to get you, you're still 'fine' using Ricochet-Refresh (based on what we know) so long as you keep your onion-service id secret and shared with only trusted people.
You guys should make it easier to donate (GitHub, link to patreon, liberapay, etc.). I cannot find an obvious way to do so with low effort or not much friction.
Ricochet-Refresh and Gosling are maintained by Blueprint For Free Speech (an Australia+Germany-based non-profit), and it looks like we've a donation page here:
The problem with all anonymous communication systems is that they suffer from network effects even more than traditional communication systems. By having few people use it you immediately expose yourself by being part of a small group of people using it, becoming an easy target. Unfortunately the reality is that it’s often easier to hide as a needle in a haystack on something like WhatsApp than it is to use a theoretically anonymous communication system that lacks the “haystack” altogether
I assume that they mean that the identity of the people running the Tor relays can be known. For example, if you run a relay from your own physical server, then your ISP knows who pays for that static IP. If you run it from a VPS or cloud, the company knows who's paying for that server.
But if you live in a liberal democracy, none of that should be an issue as far as I know, specially if you're running a non-exit node.
Most cloud/VPS providers require some form of payment. If you know of one that doesn't for any significant workload, please let me know :).
The payment providers require KYC. Bitcoin operates using a public ledger that raises privacy concerns as well.
Liberal democracy does not insulate one from responsibility for or accusations of nefarious activity.
Therefore, since it is reasonable to say that a tor node cannot be easily operated anonymously; doing so exposes the operator to some level of personal legal scrutiny that can be inconvenient and time consuming to address at best.
Authorities have been known to seize relays and exit nodes and repurpose them to their own use.
I just want to add a potential gotcha that bit me in the past:
At least with curl (or any library that uses curl under the hood) you have to be very careful to specify the scheme as socks5h:// with a letter h at the end, not just socks5. Otherwise the hostname lookup would happen directly through the client rather than the proxy.
So Tor Browser (fork of Firefox ESR with various custom patches and tor bundled in) sends all DNS requests over tor (presumably Brave does the same thing if they're doing their jobs right) via tor's SOCKS5 interface.
This means if you make a request for a clearnet service (e.g. example.com), that request goes to the daemon, which forwards it through the tor network to the exit node. That node sends a DNS request to whatever DNS server it is configured to use.
In the case of an onion-service (e.g. riseup.net's onion-service vww6ybal4bd7szmgncyruucpgfkqahzddi37ktceo3ah7ngmcopnpyyd.onion) the tor daemon itself notices 'oh hey it's a .onion tld' and will try to resolve using its internal onion-service related machinery. This type of request will never go to a DNS server.
However, it can get weird if you're configuring a piece of software that somehow is not 'tor-aware' to use tor as a SOCKS5 proxy, and then request an onion-service. In the case of curl for instance it will(would?) reject the request since .onion is not a valid general TLD (per RFC 7686) to avoid leaking the .onion name to DNS servers (see https://daniel.haxx.se/blog/2024/05/17/curl-tor-dot-onion-an... for more info).
Another failure mode is software somehow doing its DNS requests internally rather than relying on the SOCKS endpoint it's configured with:
> let ip_address = DNSResolver.resolve("www.example.com");
> let socket = TCP.connect(ip_address);
In this example, the domain name would be resolved with the user's own locally configured DNS, and then connect to the website over tor which would allow correlation of the anonymous connection with you under the right circumstances.
Yet another failure mode is if the application's protocol somehow includes local network info (e.g. your IP) embedded in its protocol's packets. If you were to naively tunnel this traffic over tor, you wouldn't actually have anonymity since the app itself would be snitching on you.
---
So in general, one should not naively tunnel arbitrary traffic over tor if your goal is anonymity. There's a reason (well, lots of reasons) why Tor Browser requires regular maintenance beyond 'lol just configure Firefox to use tor, job done'. There is a surprising amount of subtlety and complications around browsing the web over tor so if that's your goal, please just use Tor Browser.
Also in general, if you need your anonymity please do prefer software which has bundled+configured tor in it correctly, rather than just rolling your own (unless you actually know what you're doing, understand your threat model, how all these pieces interact, etc).
I'm asking because I have a web server that uses dynamic subdomains for sandboxing websites and I'm thinking about letting it run as onion service. However, the server needs to know the domain it's hosted on, which would be an .onion domain.
From wikipedia.