I think a lot of comments here are forgetting it takes months to be considered a trusted guard node by TOR. Unless you have hundreds of these and a lot of time and patience, and somehow knock off all of the non-malicious guard-nodes + have your "aged" guard nodes set up, this attack will be very difficult to conduct.
Which the larger countries do. And the main point of Tor is to evade serious adversaries isn't it? If you're not anonymous from nation states when using Tor, then what will protect whistle-blowers and investigative journalists and dissidents? VPNs can be ordered to turn over data by courts and you can never be sure a "no logs" VPN does what it says. Tor is the only viable alternative and we know it can be at least seriously compromised by the bigger nations.
Tor however has always made the disclaimer that even basic correlation attacks will defeat its anonymity. People use it as the de facto tool for beating the big guys, but it provides no such capability or claim of such. This seems to not be so well known though.
The only thing that can work against big national agencies is security in depth, in which tor can be part. Tor is also better than nothing, which is a better de factor tool than plain text.
In modern society everything gather meta data. The phone, the credit card, the mass transit system, cameras with face recognition, the isp, all the routers between A and B, the devices people own, the platforms they socialize on. Its almost impossible to make a face to face meeting without allowing nation agencies to know about it. A leaker wanting to talk to a journalist without risking becoming a target might not be 100% protected by tor, but then I don't know any single better method right now. Some combination of obfuscation, encryption, mixing, and plausible deniability seems to be the best bet.
Ie, talk in code, use VPN, use shared communication streams like Tor, and make your behavior look legit and boring. Of course I am not speaking as a professional opsec specialist agent.
not making such claims is a the only way to be taken seriously by the community it serves. Those using tor-browser know it's a best effort approach.
The same attitude should be expected from all InfoSek vendors. But it's easier to sell a product with claims it will protect you rather than saying the truth (that it's riddled with edge-cases like everything else).
Tor, unlike many of the VPN companies, thankfully lack a marketing department trying to push it with incorrect claims about its alleged ability.
edit: if the threat model is to protect against corporate mass-surveillance ("the big guys"), then Tor is incredibly effective. They wouldn't go through the trouble to identify and blacklist exit nodes and present users with a captcha otherwise. (ofc assuming that it is used correctly: never log in, or if you must only log-in with sock-puppet identities etc).
>They wouldn't go through the trouble to identify and blacklist exit nodes and present users with a captcha otherwise.
Do you really think they care about that 1% (made up number) of Tor users using their service legitimately? Or do they just want to avoid being attacked or their service being abused?
Has there been any known case where a person using Tor has been tracked down and put into curt, without human mistake that lead to his de-anonymization?
A bit more detail would be welcome about those "Hundreds, maybe thousands" of persons. Clearly the security researcher did find a vulnerability in the protocol and confirmed it by unmasking users, but I don't see the support for people getting "tracked down and put into [court]".
More important, what purpose is there to reference a 5 year old patched security vulnearbility? The same year as the above vulnerability was found in Tor, HTTPS was also broken with Heartbleed. The only fool-proof security is security in so many layers that it become statistically unlikely to cause a negative impact.
The issue isn't that the CMU people exploited the "relay early" bug. It's that the FBI subpoenaed all their data, tracked down onion services, and served malware.
This is just the outcome from busting one site, PlayPen:
At least 350 U.S.-based individuals arrested
25 producers of child pornography prosecuted
51 hands-on abusers prosecuted
55 American children successfully identified or rescued
548 international arrests, with 296 sexually abused children identified or rescued
The article says that they likely did not have a warrant and simply just went and hired the researcher directly.
But fair enough, the claim that hundreds did get tracked down and arrested, due to a bug found by a security researcher after getting hired by the FBI, is true.
People selling zero days vulnerabilities is a major problem to security. Sadly it is something which new threat models need to take into consideration. The Tor Project did change how the Tor browser bundle updates, and I suspect this event did also caused some ripples in the project in how much they can trust researchers.
It depends on who runs these attacks. Some law enforcement agency could use those attacks to put you in jail.
Mapping out Tor users can be interesting to other entities, too ...
As you can see from the original article these attacks happen. They are also run against more interesting websites or individuals. Obviously, the attackers won't write a publication for their vulnerabilities ;)
Related: https://medium.com/@nusenu/the-growing-problem-of-malicious-...
Once in while, Tor node operators will complain about DDOS on the tor mailing lists or similar sites. In most of the cases this is just an attempt to figure out guard nodes or real IP addresses of an individual or server.
> More important, what purpose is there to reference a 5 year old patched security vulnearbility?
Sure, it's old, and everyone screws up sometimes.
A few things bother me about it. One is that we know that the Tor Project did notice the malicious relays that CMU people were hosting. From what I've read, they weren't subtle about it.
So basically Tor Project staff said that they screwed up, and apologized. But somehow that just doesn't feel plausible.
There's also some email obtained through FoIA which could be read as evidence that "Tor developers are closely working with the US government".[0]
Sure, maybe that's just paranoia and conspiracy theory. And I do appreciate the delicacy of supporting strong anonymity for Tor without defending child pornographers.
(I don't have a link handy and I'm going from memory here so I apologize if I've screwed anything up...)
There was a Harvard student a few years ago who got busted for e-mailing a bomb threat (during finals, maybe?) or something like that.
The school reviewed their (Netflow?) logs, found the users on their network who were using Tor at the time and so he quickly became a suspect (and confessed when questioned, IIRC).
If he hadn't been on the school's network, it would have obviously been much more difficult, if not impossible, to find him so I suppose this one could be classified as an opsec fail.
I2P was rather like the love child of Freenet and Tor. Like Freenet, it's pure P2P, where all users route traffic for each other. And although there are outproxies to the open Internet, it's mostly about I2P-hosted content. If anything, it's mostly like Tor onion services.
It uses a version of Tor's onion routing, called garlic routing. The main difference is that I2P tunnels are unidirectional, whereas Tor tunnels are bidirectional. That will allow for content caching and bundling, but that's not implemented yet.
There are reportedly ~10^4 I2P nodes, versus ~2x10^6 Tor users and ~6x10^3 relays. It's been argued that unidirectional tunnels are harder to deanonymize than bidirectional tunnels. But on the other hand, all I2P nodes are readily discoverable by malicious peers, but Tor users are much harder to discover, because Tor clients don't change guards frequently.
So bottom line, they arguably provide similar anonymity.
Edit: Yes, guards can discover users. But Tor is designed to make it hard for a given guard to see that many users. So you'd need lots of guards. And that's not so easy, because Tor folk are constantly on the lookout for suspicious guards, especially when a bunch show up at the same time.
> but Tor users are much harder to discover, because Tor clients don't change guards frequently.
I don't get that. Every guard can discover users because the users directly connect to guard nodes. As a guard you can just collect the real IP addresses of Tor users except they use a VPN or proxy to connect to the Tor network.
Can't edit my other reply.
The operator in the OP runs 68 nodes. I did not look at each one, but it looks like most, if not all of them are guard nodes. This article mentions someone running at least 10% of the guard capacity: https://medium.com/@nusenu/the-growing-problem-of-malicious-...
Tor's design obviously failed. Everyone can become a guard. You just need some patience. Also other nodes like DirAuths, bridges, fallback directories can discover Tor users.
Yes, that is an issue for Tor. But it's still arguably worse for I2P, because all peers can connect to each other.
But regardless, that's why I never use Tor or I2P from home, except through nested VPN chains. I don't care so much about VPS, because I'm very careful to isolate myself from them. For dedicated servers, however, which are more expensive, and where I invest more work for setup, I also use nested VPN chains.
There are single operators that run dozens of nodes. Just take a look at the article.
Anyone can setup nodes and give no contact info or just change it to something else.
I could spin up nodes as gzer0 and the next week add new ones as gze1. You could run hundreds of nodes as a single person without anyone noticing it.
>and a lot of time and patience
Tor has been around for a while ...
Creation of nodes, which mostly are just VM's running in some datacenter, can be automated to some extend.
> and somehow knock off all of the non-malicious guard-nodes
There is no need for that. When you become the malicious guard of someone, by design, you can run correlation attacks for months. Just be patient and probability will do the rest for you.
Also when being a guard you get the IP addresses of Tor users. Using Tor puts you in a group consisting of "interesting" people. No, these are probably not thousands of whistleblowers and people from oppressed regimes (well maybe russia). The majority of traffic comes from the US, and western European countries. Interesting people are: hackers, fraudsters, crawlers (guess why many sites block Tor), drug dealers, drug users, pedophiles, literally everything (cyber)crime and people having something to hide. A list of those people would be quite interesting wouldn't it? Even if there would be thousands of whistleblowers these are persons of interest, too.
First: it seems like the author has come up with a number of useful custom modifications to the Tor daemon to mitigate common attacks against onion operators. Why not work with the Tor Project to upstream some of the more useful ones, as well as the additional debugging information? Reading past Hacker Factor posts, is it just me, or is there a tone of slight disdain towards the Tor project?
Second:
>However, there's a second attack. The attacker can run one or more hostile guard nodes. If he can knock me off enough guards, my tor daemon will eventually choose one of his guards. Then he can identify my actual network address and directly attack my server. (This happened to me once.)
A guard node is going to get a lot of traffic from both onion services and normal Tor users. How can an evil guard node tell which IP belongs to the author's server?
Overall, this is startling to read. History suggests that it is only a matter of time before an onion service gets unmasked by the latest attack on the Tor network.
Onion services are incapable of resisting a determined government-scale attacker. Just filter Tor traffic to random groups of users for like 10 seconds, find one such groups that prevents the target onion service from being routed. Bissect until you locate a precise node.
IMO, Tor is to be used to escape censorship as a reader or host services anonymously in not tech-savvy governments (which are becoming increasingly rare).
In the end, Tor only buys 10 to 20 years of freedom until governments figure out what to outlaw and filter. Censorship is a political problem, technical solutions provide a temporary hotfix, but the political problem has to be solved at one point.
> Just filter Tor traffic to random groups of users for like 10 seconds, find one such groups that prevents the target onion service from being routed. Bissect until you locate a precise node.
That only works if you have the ability to filter out Tor traffic in the first place. (In which case, why not just preemptively block all Tor traffic in your country? Problem solved.) But Tor has systems in place designed specifically to prevent that sort of blocking by disguising Tor traffic as other, more common traffic types (like HTTP).
There's also no guarantee that the Tor service in question is running on a host that's under your government's control. Cloud hosting is pretty common these days.
Yes, you can ban Tor altogether and be done with the whole thing. It is doable and there is no technical workaround for it.
The scenario I am proposing is actually worse: you use the feeling of anonymity Tor proposes to uncover opponents. Yes, my tactic proposes you have a backdoor into all of ISP's infrastructure. I don't see that as a crazy requirement for most countries, even democracies.
Disguising Tor traffic does not work well, and China has deployed several years ago already a tech that recognizes weird streams.
Yes, you could be cloud hosting from outside the country. In the case of China though, that's likely to not work as most encrypted traffic crossing the border gets dropped (I guess unless it is HTTPS from a whitelisted source )
Lots of onion services have been deanonymized. The "relay early" bug that CMU researchers exploited deanonymized perhaps hundreds of sites. And, both directly and indirectly via malware served by compromised sites, thousands of users.
There's been much discussion since mid 2019 on the tor-dev list about DoS defense measures.[0]
I consider Tor to be completely compromised. Consider this:
1) Political entryism by ideologues. These people stand against merit, and these are the same people who every few weeks post a lead-balloon of a thread against it in this very forum and others.
2) Recent purge of non-aligned team members on trumped up bullshit that only offends the now-dominant political ideas
3) Large, long redesign with obvious flaws
4) Unwillingness to address the reported flaws
We are not talking about ICQ here, we are talking about Tor. If the Tor team is not concerned about this, then what are they concerned about? What else are they even doing? Why is it that in this age of total surveillance, when even Torvalds had to face the wall while they purged his team, nobody in power is bothered by Tor? Ain't that the fucking shit?
I do share the concerns about Tor's security, and about the Tor Project's focus. However, I don't believe that it's useful to argue about the culture war soap opera. As an attentive outsider, it strikes me as largely based on hearsay and innuendo. But still, that's a valid concern, to the extent that it interferes with developing and securing Tor.
What bothers me most about the Tor Project is how it seems to focus on ~OK anonymity and security for most users, and seems to ignore vulnerabilities that impact users who are most at risk.
While Tor browser is very well hardened, relative to Firefox, there's absolutely no protection against malware (or anything else, for that matter) reaching the Internet directly, and so bypassing Tor. And that's precisely what hosed thousands of users who were infected with the FBI's malware, which phoned home, and got them busted.
I don't deny that many of them were accessing child porn. But when we're looking at Tor's security, that's arguably irrelevant. I mean, we know about this because criminal matters in the US are public. However, we have no clue how many users in authoritarian regimes have been pwned by similar malware, over what we'd call human rights issues.
And it's not hard to fix, really. All you need is firewall rules that allow only the Tor process to access the Internet. That's doable with Windows Firewall. But I've never seen anything about that on the Tor Project site.
In Linux, it's harder, because there's no way (that I know) to control network access by process. Only by user. And here's another screwup. In Debian, plain vanilla Tor runs as user debian-tor. So it's easy to allow output only by that user. But Tor browser runs the tor process as the login user, so that approach doesn't work. You can use iptables rules that allow output only to requisite relays, but that's brittle to guard failure.
> there's absolutely no protection against malware (or anything else, for that matter) reaching the Internet directly, and so bypassing Tor.
This is where something like Whonix[1] is helpful. You’re right that torproject.org doesn’t mention this issue much at all with regard to Tor Browser usage. On the other hand, the warnings are fairly obvious in the TorifyHOWTO[2] section.
>While Tor browser is very well hardened, relative to Firefox
Some say it is one of the most attacked browser ...
>However, we have no clue how many users in authoritarian regimes have been pwned by similar malware, over what we'd call human rights issues.
Maybe not as much as you believe. The OP is talking more about traffic correlation. The FBI's attack came from the browser, this can also aid in correlation attacks but was irrelevant in the FBI's case.
In authoritarian regimes you can just attack from the network side and log each IP which tries to connect to a Tor node. Then you visit those people personally. Or like in so many authoritarian regimes you just block Tor completely. Neither a firewall or Tails or Whonix will protect you against traffic correlation attacks.
You can use unregistered obfuscating bridges when the Tor protocol is banned. Not sure how effective that is though, since I've never needed to use them.
> And it's not hard to fix, really. All you need is firewall rules that allow only the Tor process to access the Internet. That's doable with Windows Firewall. But I've never seen anything about that on the Tor Project site.
Generally malware on the local system is nearly always game over. There's little you can do about it without wiping the system. But other than that I suppose the Tor project could give more visibility and advocacy for both Whonix and Tails, as they provide better system-wide protection than the Tor Browser can do. As you say, neither of those well known projects are mentioned anywhere easily locatable on their site.
I agree that malware means game over. But firewall rules at least protect against wimpy malware.
And yes, I really don't know why they haven't embraced Whonix.
What's funny is that Tails has more visibility, and it's actually less effective against malware. Because there's no isolation between userland and the Tor client.
Freenet is pure P2P, and there's no option for Internet access. Also, it doesn't do onion routing like Tor or I2P do. It employs a sophisticated encryption and forwarding strategy, to obfuscate senders and recipients from innocent intermediaries. So arguably, any peer can plausibly claim that they're just an intermediary, handling end-to-end encrypted content.
However, given logging data from malicious peers, adversaries can discover peers that handle illegal content. Then they can attempt to distinguish senders and recipients from innocent intermediaries, through statistical traffic analysis. And then they can arrest and prosecute them. And defendants must then counter claims about attribution.
The default is Darknet mode, where nodes only peer with people who they know and trust. But given how people are, it's hard to prevent infiltration.
Also, with a Darknet, there's no access to the rest of Freenet. The recommended option is having one node in a Darknet also run in Opennet mode. So then they're the only one at risk. But that funnels all Darknet traffic with the rest of Freenet through them.
Anyway, Freenet is interesting. But I do not recommend using it, except on a thoroughly anonymous VPS, managed and accessed through nested VPN chains and Tor.
There are not that many people capable of a secure design & implementation. But that is just the tip of the iceberg; any network promising anonymity requires a large number of nodes (and high traffic), and that number must stay significantly larger than the number of malicious nodes that try to deanonymize the network.
Adoption remains a huge challenge (and not really one you solve with technology or skill). It doesn't help that design decisions that improve security can degrade the user experience, leading to lower adoption and lower security. Sigh.
I left it as "network effect". Probably too opaque.
It's like there was a window in the early 00s, when stuff like Tor, Freenet and I2P could recruit enough nodes to be viable. Remailer networks were just too damn hard to use. I mean, they were based on PGP plus mix networks.
I have read the articles, but have not found an explanation or specific examples. It's not as if Tor doesn't care about onion services; they just spent 4 years designing and implementing the v3 onion service protocol.
It's pretty obvious when one gets stonewalled for political reasons when attempting to contribute to a project.
He doesn't need to provide specific examples or explanations, doing so just makes the issue worse. Often these issues involve specific people and specific intuitions that will be hard to interpret without lots of context. It will put the problem people on the defensive and likely cause some sort of outrage or personal attacks, or other unwanted drama.
Being polite yet firm on his own page is the best that can really be done in these situations. It allows the technical problem to be magnified while not focusing on drama.
Looks like it primarily comes from two ASN's in Brazil: CLARO S.A. (AS28573) and TELEFÔNICA BRASIL S.A (AS18881). Interestingly, it looks like Brazil is right up there with Russia when it comes to total number of risky ASN's.
Because a lot of abuse comes from Brazilian IPs. Maybe because people in Brazil have enough money to buy a computer, but not enough money to buy computers that can run the latest versions of Windows?
> many bots will only do one HTTP connection at a time (single threaded)
Is it only service admins who do such detective work, or do admins of intermediate nodes also try to filter out bots? I wonder if simple API calls wouldn't get caught in the crossfire.
Why would people spend effort trying to deanonymize an Internet Archive server? Are try trying to deanonymize every single hidden service?
And why would they try to DDOS the services once deanonymized? I don't see how anyone would gain anything from that. If you DDOS some big website you get famous from all the news articles being written about you, but DDOSing a hidden service won't make you famous.
I don't know this attacker's reason. I only see the attack.
But I can offer some baseless suspicions:
I'm forwarding traffic from Tor to the Internet Archive. During the last French election, someone DoS'ed most of their media outlets. As a result, lots of French people used Tor to access the current news from the Internet Archive's collection. Shortly after that, someone tried to DDoS my onion service.
With all of the voting and elections and the impeachment vote coming up, I'm expecting attacks since the Internet Archive stores lots of information that the current administration tried to remove from the Internet.
Then again, it could be a "researcher", or just someone seeing if it can be done. Perhaps they will decide what they want to do after their attack succeeds.
Isn’t the point of anycast to absorb the brunt of the attack? If your traffic is localized, maybe dropping the announcement for that PoP would be useful.
If they want to find out whether a deanonymization technique works, they would choose a target whose identity and location is already known, so that they can confirm that the attack produced the right answer.
From what I understand the DDoS is necessary to force the Tor daemon to choose a new guard which is what they need for their attack.
As far as deanonymizing it goes, one theory could be that it’s an automated process that crawls the open web for onion links and tries to deanonymize them all.
Also is it not weaker from an anonymity standpoint for the tor deamon to choose the same nation for the entire Tor circuit? I just fired up Tor Browser, navigated to the Tor Blog and this is what I get:
Why do you suppose the Tor project has been so resistant to mitigating this class of attack? In particular, the proposal to require that rendezvous nodes be publicly listed seems sensible to me, and I wasn't immediately able to find any Tor bugs on the subject.
That's a good question indeed. I don't have an answer but some people got similar results when pointing out some issues internally. Only when publishing those on the mail list where everyone can read it things started to gain some traction.
"In April 2018 a Tor core member — the most active Tor Project person on that closed mailing list — made an attempt to initiate a “do not do” relay requirements list to improve and streamline the handling of malicious Tor relay reports. (I’m not mentioning his name since he does not want to be publicly associated with bad-relays handling for safety reasons.)
Unfortunately also this attempt failed since no Tor directory authority operator answered. (Tor directory authorities are required to enforce any Tor network wide rules unless it is part of the tor code itself.)
Starting with June 2019, after multiple reports about suspicious relays remained with no reaction I stopped sending them to the list. Occasionally I sent some suspicious relay groups to the public tor-talk mailing list instead — which ironically was more fruitful."
Even more ironical, the very person which reported that issue and similar ones (also on twitter) got his twitter account closed shortly afterwards (see other post on that site). So he has much less audience than before. Coincidence? Tinfoil hattery? Maybe. But certainly fishy.
I wonder if Wireguard is dynamic and lightweight enough to be hacked into re-implementing something like tor but that dynamically shuffles data paths in flight ?
Actually, that works well enough with OpenVPN. I've managed a crude setup that switches two-hop nested VN chains at 10 minute intervals.[0]
I should also have mentioned the Orchid app for Android (and perhaps soon for iOS).[1] It implements dynamic multi-hop routing, and reputation-based route selection. As I understand it, commercial VPNs are providing OpenVPN servers for the network, and I would hope that each hop uses a different provider. Users buy bandwidth with supposedly anonymous Etherium-based cryptocurrency.
Orchid may provide privacy and anonymity that's at least comparable to do-it-yourself nested VPN chains, and perhaps comparable to Tor. In that you're distributing information and trust among multiple providers, who are paid anonymously. And it's obviously far less work than nested VPN chains. But as with Tor, there's the downside of trusting a complex system, which you likely won't understand well.
There's also the issue that current smartphones are so horribly insecure that using such tools arguably provides merely an illusion of security, privacy and anonymity.
> However, there's a second attack. The attacker can run one or more hostile guard nodes. If he can knock me off enough guards, my tor daemon will eventually choose one of his guards. Then he can identify my actual network address and directly attack my server. (This happened to me once.)
I also worry about malicious guards. For local machines, I only hit Tor via nested VPN chains. So even if I'm using a malicious guard, the attacker will just get the IP of the exit VPN server.
For onion services, I typically use VMs in dedicated servers. And so I can put at least one VPN-gateway VM between the onion server VM and the Tor guard.
You could also get all of the guards from tor's state file, and hard-code them in torrc with EntryNode. That wouldn't prevent an attacker from taking the site offline, but at least they couldn't become your guard.
Bitcoin full nodes running over Tor can also be attacked similarly? I think yes however not sure and not every full node over Tor follows same configuration
All crypto services should be run through a decentralized, extra-codebase voting scheme to generate a confidence interval. Mature services like Bitcoin should have multiple clients and client versions available, geographically distributed across a range of networks, frustrating identification and creating an aggregate mechanism for rapidly detecting anomalous output and mitigating unknown attacks. I implemented this ~8 years ago.
Wouldn't your onion service uptime become correlated with the guard's uptime? DDoS probes as described in the OP plus some basic monitoring of known onion sites could discover onions paired with single guard nodes. And if I can become certain that the guard node is owned by the onion operator, you're one subpoena away from deanonymization.
>Wouldn't your onion service uptime become correlated with the guard's uptime?
Yes. This is happening on a fairly regular basis. ddos against a tor node in most cases is just trying to figure out someones IP address or guard node.
If you run a big darknet site dealing with things like drugs, CP, fraud, and you want to stay around for a while you need to run lots of nodes otherwise you will be pwned probably within hours. There is no point in doing that for legal onions sites like facebook because everyone knows their real operators.
Now when you run lots of nodes and at the same time a big website on the darknet you are in the perfect position to run traffic correlation attacks yourself.
There is some tutorial available which suggests using some deceptive methods to spoil such tracing efforts. For example when website A is going down you also shut down your site. Or when there is a big blackout of AWS US etc
Running your own guard is stupid unless you open it for the world to use.
If you're the only person using the guard, then the guard offers you zero anonymity.
And if lots of people use your guard, then make sure it doesn't violate your ISP's terms of service. (Most ISPs have a clause about residential customers not running public services.) Also, have a plan in place for when (not if) you receive legal notices about copyright infringement, child porn distribution, and other acts that could be criminal in your country/city.
As long as you're anonymous enough about it, I don't see why running your own [private bridge] is any less anonymous than using an unpublished bridge, or a snowflake proxy.
An adversary with lots of intercepts could certainly figure it out. But otherwise, how would anyone know?
And at least, it protects you from malicious guards.
Also, your point about violating a residential ISP's ToS is troubling. Because nobody in their right mind ought to be running any sort of Tor relay from home. It's a ~sure way to get your IP address on many blocklists.
And about getting notices, that only happens for exit relays. Not for guards and middle relays.
Edit: Actually, I meant running your own unpublished bridge, not guard. In the bridge torrc:
A malicious guard is just a malicious node. It can also be used as some other hop, or there can be non malicious nodes without a guard flag. I think there has been at least one publication taking a closer look at what malicious middle nodes can do.
I'm not familiar with bridges or the snowflake proxy but I think this would work:
Public bridges are public so no one cares about those. Now you run your own private bridge. First of all running your own leads directly back to you. Second it puts you on the list of even more paranoid people. Since you know and connect to that private bridge one can assume you trust that bridge for whatever reason which indicates some kind of "personal" relationship to that bridge.
The private bridge now connects to the second hop. This is a malicious one. The operator sees an IP which does not come from an official relay in the consensus. I don't know if a node knows he is in the middle (at least a guard and exit must know they are at the beginning and end of a chain, i guess?), but if he does he would now know that a private bridge is connecting to it. So you could enumerate private bridges.
If someone runs dozens of nodes, which is actually happening, this looks like a viable option. Correct me if I'm wrong.
> First of all running your own leads directly back to you. Second it puts you on the list of even more paranoid people.
It doesn't point to "me", at least in meatspace or even as Mirimir. It points to some anonymous persona, created specifically for that purpose. On its own Whonix instance, through its own nested VPN chain, and using its own multiply mixed Bitcoin. All totally disposable.
And to be clear, I'd use a different anonymous persona for the onion service itself, created specifically for that purpose. With all the features described above.
> Since you know and connect to that private bridge one can assume you trust that bridge for whatever reason which indicates some kind of "personal" relationship to that bridge.
There are numerous private bridges, and many of them have only a few users. Perhaps even just one user.
> The private bridge now connects to the second hop. This is a malicious one. The operator sees an IP which does not come from an official relay in the consensus. I don't know if a node knows he is in the middle (at least a guard and exit must know they are at the beginning and end of a chain, i guess?), but if he does he would now know that a private bridge is connecting to it. So you could enumerate private bridges.
Sure. Authoritarian regimes do that all the time.
But here's the thing. My Tor client will still only use that bridge. So it can't be tricked into using a malicious bridge. And I can change private bridges frequently, if I like. It's not at all hard to configure them.
First: If you're going to do that, then why bother with Tor? Just get a couple of private cloud boxes and make your own VPN. (You'll be just as secure. Which isn't as secure as Tor, but it's better than nothing.)
Second: "An adversary with lots of intercepts could certainly figure it out." Exactly. If you use Tor properly, then nationstates with virtually infinite resources can't figure it out. (That's why some countries block Tor; if you can't crack it, then block it.) But if you run your own guard, relay, rendezvous, or exit node -- and you're the only person who uses it -- then an adversary with lots of intercepts could certainly figure out who you are.
I bother with Tor because it's this onion routing network that's pretty large and well used. And maybe even ~secure and ~uncompromised, but counting on that is iffy.
I mistakenly said "running your own guard". What I meant was "running your own bridge". But in practice, that's basically the same.
But it's disingenuous to claim that even using a private guard (which isn't possible, as far as I know) is "just as secure" as a private VPN. Because there are still two other relays in its circuits to introduction and rendezvous points.
It is less anonymous, I admit, but it's also less vulnerable to malicious guards. And from what I'm aware of, malicious guards have deanonymized far more users and onion servers than traffic correlation attacks have.
> If you use Tor properly, then nationstates with virtually infinite resources can't figure it out.
That's just plain wrong. Even the Tor Project admits that.
But in any case, I'd never count on servers remaining uncompromised. I'm very careful to avoid associations with them.
Edit: Here's a little thing that I sometimes do, if I really want to obscure an SSH login or whatever.[0] Basically, I can do a Tor plus VPN based version of the old telnet login chaining thing.
>But it's disingenuous to claim that even using a private guard (which isn't possible, as far as I know)
I have been thinking about this for a while, too. There is some Tor fork which allows non-exit nodes to exit. It has been posted on tor-talk a while ago.
For a private guard you would need to change the local consensus file and include the private guard. Then you would also need to control the next hop so it recognizes your guard as first hop and connect you to the third hop. I don't see why this won't work in principle.
So you could have Tor exits that aren't published.
That would get around the CAPTCHA plague for Tor users.
Another option that I've considered is IPv6. Relays with both IPv4 and IPv6 must publish their IPv4, in order to get OKed for use. But as far as I know, there's no reason why they couldn't preferentially push exit traffic through IPv6. And indeed, use a different IPv6 address for each circuit.
Operators of Internet sites have the ability to prevent traffic from Tor exit nodes or to offer reduced functionality for Tor users. ... The BBC blocks the IP addresses of all known Tor guards and exit nodes from its iPlayer service, although relays and bridges are not blocked.^[110]
The above is from the Wikipedia page for Tor. If the guard IP was "unpublished", then would that be a way to access sites like BBC iPlayer in spite of their blacklisting known guard IPs. Perhaps in the BBC case some users were trying to use Tor as a "poor man's VPN" to get a free UK IP address.
I work on infrastructure at Discord. Our voice and video infrastructure gets attacked quite frequently and we have pretty good tracking about which ASNs the traffic is coming from as part of our mitigation processes.
Anyway, Choopa is a common source of DDoS in our reports, so I can corroborate the OP's comment to some degree. They aren't the largest we see, but they're in the top 10 sources for us.
As someone who used to work for a company that hosted large-scale gaming infrastructure, I can confirm that Choopa was a common source of DDoS. DigitalOcean, too, and lots of eyeball providers. Any provider who allows credit card payments has issues with outbound attacks, and some are better at responding quickly than others.
It got so bad we ended up building and deploying our own line-rate packet processing engine at our network edge to be able to deal with the weird UDP protocols gaming uses.
This finally hit the tor-dev list.[0] And Mike Perry's post is somewhat alarming.[1]
Some excerpts:
> The "Oddly, sometimes the connection would succeed" sentence is a red flag sentence. If you are inclined to be paranoid, there is indeed a way to hide a real attack in what looks like a simple ntohl() bug here.
> This "sometimes"connection behavior is often seen in tagging attacks, where the adversary abuses Tor's AES-CTR mode stream-cipher-style properties to XOR a tag at one end of a circuit, and undo that tag only if the other endpoint is present. In this way, only the connections that actually succeed are those that the adversary is certain that they are in both positions in the circuit (to perform Guard discovery, or if they are the Guard relay, to confirm deanonymization).
> If you want to hide your tagging attack as what looks like a simple ntohl() bug here, you send your intro2 with the reverse IP address. Then, when your middle node suspects a candidate rend cell (via timing + circuit setup fingerprinting, to have a guess), it can confirm this guess by undoing the tag by XORing the cipherstream with ntohl(ip) XOR ip.
> <snip>
> Aka a correctly performing rend cell tag hidden in what looks like a very common networking bug.
> BUT DON'T PANIC: There is also an alternate explanation for the "sometimes succeed" red flag in this particular case, other than a tagging attack.
> <snip>
> So most likely, this is just a poorly written Tor client, but there still is the possibility that it is an attack cleverly disguised as a poorly written Tor client.. :/
> It may be a good idea for Neal's/our monitoring infrastructure to keep an eye on this behavior too, for this reason, to test for the side channel usage + rend XOR "correction" vs just dumb bug that is sometimes connecting by getting lucky (and thus never properly reverses the rend IP address). If this is indeed just a bug, when these rends do succeed, the IP address should never be correct.
> The way to do that would be to build rend circuits using 3rd hops that you (the service operator) control, so that that 3rd hop can check if the rend succeeds because the TLS connection happened to be open (benign behavior) or because the reversed ntohl() got corrected somehow (attack).
> Even after deployment of the new v3 onion service protocol, the attacks facing onion services are wide-ranging, and still require more extensive modifications to fix in Tor-core itself.
> Because of this, we have decided to rapid-prototype these defenses in a controller addon in order to make them available ahead of their official Tor-core release, for onion services that require high security as soon as possible.
