Deanonymizing Tor Circuits
hackerfactor.com
hackerfactor.com
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.
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.
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.
Not one person. Hundreds, maybe thousands. Because of a exploited vulnerability, and failure to pay attention to an upsurge in suspicious relays.
Unless you consider that the mistake was using Tor directly, rather than through a VPN service.
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.
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.
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.
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.
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).
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?
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.
Go on.
As far as you know.
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.
Tor is not as secure as it (maybe) once was.
Related reading: https://medium.com/@nusenu/the-growing-problem-of-malicious-...
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.
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.
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.
There's been much discussion since mid 2019 on the tor-dev list about DoS defense measures.[0]
0) https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-de...
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?
But I haven't given up on it entirely.
I mean, what else do we have? VPNs, sure. And maybe I2P. But it'd be very sad if Tor were totally compromised.
However, I2P is the only alternative that's been implemented at any scale, to my knowledge.
Papers have been published, yes. But I'm not aware of any other anonymity networks that have even gone public.
Why that is, I'm not sure. Maybe it's just network effect.
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.
But now, people expect stuff to be easy.
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.
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.
Anyway, enough already.
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.
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.
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.
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.
[2] https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWT...
And about the TorifyHOWTO, the dumbed-down website redesign has made that stuff even harder to find than it was before.
What about https://github.com/gustavo-iniguez-goya/opensnitch ?
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.
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.
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 )
ExcludeExitNodes {br}
source: https://www.recordedfuture.com/asn-blocklist-analysis/
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.
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.
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.
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.
If the IA itself was DoSed then wouldn't your relay stop working?
"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."
https://medium.com/@nusenu/the-growing-problem-of-malicious-...
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.
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.
It "falls flat" if you're using a malicious guard. But then, you're already screwed, in that case.
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
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.
It's OK to use guards for yourself because
1) there are thousands of non-public guards(bridges) 2) you choose the path to the rendezvous point 3) middle nodes don't know the type of the traffic
Also there are a few things wrong with your article.
And the rendezvous point must be in this list (because you shouldn't have a private rendezvous node). Usually Choopa LLC -- a cloud provider that is regularly used by hostile actors. However, the relay, rendezvous, and exit nodes must be publicly known so that lots of Tor traffic will use them.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.
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.
How much spoofed traffic do you see nowadays?
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:
ExitRelay 0
BridgeRelay 1
BridgeDistribution none
PublishServerDescriptor 0
UseBridges 1
UpdateBridgesFromAuthority 0
Bridge [transport] IP:ORPort [fingerprint]Paying and managing is separate. And yes, also uses Tor, plus nested VPN chains.
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 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.
0) https://www.ivpn.net/privacy-guides/onion-ssh-hosts-for-logi...
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.
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.
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]
110. https://www.bbc.co.uk/iplayer/help/questions/playback-issues...
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.
Sites like the BBC don't see guards, or middle relays, just exit relays.
However, Tor relays are exits only if their torrc has this:
ExitRelay 1
It takes a while to earn the guard flag. But eventually, some relays could fill all three roles: guard, middle, and exit.
As far as I know, bridges are the only Tor relays that can be unpublished.
A private/unpublished bridge, yes. But if you just run a relay with ...
PublishServerDescriptor 0
But then, I haven't tested that.
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.
> This cipherstream tagging weakness has had a few proposals to fix, most recently: https://gitweb.torproject.org/torspec.git/tree/proposals/295...
> 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).
0) https://lists.torproject.org/pipermail/tor-dev/2020-February...
1) https://lists.torproject.org/pipermail/tor-dev/2020-February...
> 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.