Tor is not as secure as it is often thought. It needs to be redesigned and/or adopt some modifications from I2P's "garlic routing".
I suggest a complete end-to-end rethink of how anonymous Internet services are done. Instead of it being a tunnel for generic traffic, think of a specialised private protocol for input/output of information. Throw away the highly complex, insecure HTML5 that most hidden services are interacted through. Instead of slow, bloated HTTP requests, think of sockets that stay alive meaning traffic can be high bandwidth and low latency. We could even throw in some modern cryptography like ED25519 which would give some performance benefit. I had an idea for 'heartbeat groups' too which would prevent timing attacks at the ISP/wider Internet level.
If it weren't for the fact that I have a full time job and don't want the Five Eyes on me, I'd build it myself.
And what exactly qualifies you to make those statements? Especially since what follows IMO reads rather bizarre.
> I had an idea for 'heartbeat groups' too which would prevent timing attacks...
Great! What is this supposed to be? Is it some kind of mixing scheme? How does this prevent timing attacks? How did you model this to verify those claims you make? Do you have a publication on that somewhere?
> If it weren't for the fact that I have a full time job and don't want the Five Eyes on me, I'd build it myself.
In other words, you know better than the people who did the existing implementation, but really can't be bothered right now?
You got me a bit curious, but since you have no description or website link in your profile and a Google search for your nick only leads me back here, I started browsing through your comments, trying to find some details on your background in IT-security. Besides a bunch of strong opinions on practically every topic thrown at you, I didn't manage to dig up anything interesting so far.
Somewhere in your early comments, you said, your work entails managing bare metal machines. Somewhere else you said your job is basically skim reading docs. There are some other references to systems administration topics as well. Are you by any chance some kind of data center sysadmin?
I'm sorry and I'll gladly stand corrected, but for now there are simply too many red flags here for my taste.
What qualifies me? It's my opinion, I don't need qualification to have an opinion and you don't need to care about it. But since you asked, I'm a privacy enthusiast with a good understanding of cryptography (not PhD level and I would never claim it to be). I don't see why my job is relevant.
I've wanted to reinvent hidden services for years and you're wrong about it being a matter of motivation. It really is a matter of both time and not wanting to bring attention to myself.
Not sure what you mean by heartbeat groups, but if I'm guessing correctly this sounds fairly similar to chaffing and winnowing https://en.wikipedia.org/wiki/Chaffing_and_winnowing which lets information from multiple senders (or even bogus, non-existent senders) to be clumped together and broadcast in such a way that every destination is able to pick out only the messages intended for them and cannot distinguish messages not meant for them from uniformly random garbage.
I have an acquaintance that's a mid-to-high level FBI agent. In casual conversation, he's eluded on more than one occasion that the government is able to track people using TOR. I believe his exact words were "we've gotten pretty good at it." At this point, I just assume the government knows about everything I do online.
I suspect they are exaggerating, or that the claims were misunderstood. Yes, the FBI can find criminals who use Tor, but with extremely few notable exceptions from many years ago now, that isn't done by breaking any of Tor's protections, but instead using more traditional police investigation methods (e.g., "we got a tip this person is up to something, and this account only ever posts when that person is at home..."). We know this because details of investigations are public once they go to court in the US. Yes, parallel construction is a thing, but the idea that they regularly make use of exploits and this information never gets leaked in any sort of verifiable way (even with FBI agents who are apparently willing to speak of such secret programs with mere acquaintances ;)) means we can be relatively confident that, if such exploits do exist, they are rare enough to be too expensive to waste on anything but the most extreme circumstances. In other words, no, the FBI does not know what you're doing on Tor (assuming you're not at the far end of a bell curve, and ignoring everything other than what Tor protects).
Regular surfing via TOR is so painful (due to captchas from Cloudflare and others) that the proportion of "suspicious" traffic must be quite high in the network.
It's really surprising to me that Tor is considered de facto the most secure by many, but whenever I review I2P my impression is always that it's better designed than Tor.
That's a reasonable default for 99% of Tor users. For that last 1%, there is the safe/safer/safest slider bar that is a single click away.
Javascript also has nothing to do with these attacks. Even if you turn off Javascript, KAX17 can still attempt end-to-end correlation attacks. This is much scarier than a Javascript browser exploit.
"... how do they know that these various nodes are correlated with one another ..."
The OP alludes to this:
"... and the fact that someone runs such a large network fraction of relays “doing things” that ordinary relays can not do (intentionally vague), is enough to ring all kinds of alarm bells."
... and the OP is "intentionally vague".
I, also, am very interested to know how they correlated them and what the interesting behavior was that they exhibited ...
> Some of KAX17's relays initially had used that email address in their ContactInfo but soon after these relays were setup the email address got removed from their configuration.
They don't need correlation. Operating large numbers of nodes gives them a high enough probability that all three hops may be under their control thus they can observe the entire route.
Instead of messing with your path selection a better strategy would be just run your own guard nodes that you trust (a guard node is the first node that you connect to in a Tor circuit) and to stick with them. Remember, de-anonymization attacks require the attacker to control both the guard node and the exit node at the same time.
If you want your guard node to be helpful in anonymizing your traffic, you should really make sure it's public and used by some % of the global user base (so that your traffic blends in the noise).
Once you do that though, you will always have to trust that node a little less than you could if it was walled-off so it would only serve you, just because it is another machine serving connections on the internet that will likely be targeted by adversaries who would benefit from turning many of the guard nodes into part of their Tor de-anonymization service.
If I had endless resources and was truly paranoid, what I'd do is build my set of public guard nodes, make sure they're serving Tor traffic, etc.
But then, I'd "borrow" those IPs occasionally for trusted nodes which will only accept connections from me (ideally both sets of machines will be live and routing traffic simultaneously).
In theory, you could apply the same tricks with similar success to exit nodes of course (though as usual, running an exit node is generally a slightly riskier / harder thing to do)
> That only works if the attacker doesn't know the guard node is you.
That's not how Tor nodes work. Once you setup a guard node (and it got enough reputation) you won't be the only person using the guard node. Also de-anonymization attacks require you to know the traffic coming to the guard node (and if you run a trustworthy one yourself and you're not dealing with a global passive adversary then there's no way the attacker will be able to see the incoming traffic to the guard node).
Running your own node and "sticking with it" is not a great idea especially if you're the only one using it. You will be spotted and identified pretty much instantly
Does an attacker only need to control the guard and exit nodes, or the middle relay node(s) as well?
If the latter, can you configure Tor to use more than one middle relay node, depending on your threat model?
Could Tor do something like overlay a fixed-throughput circuit-switched network on top of the packet-switched network to prevent correlation attacks? Obviously at the expensive of efficiency.
Also: If KAX17 is running nodes on 50+ AS's "including non-cheap cloud hosters like Microsoft" shouldn't it just take one insider at one of those hosts to leak the identity of one or more of these node operators? Come on, guys...
> Does an attacker only need to control the guard and exit nodes, or the middle relay node(s) as well?
No, only controlling the guard and exit nodes is necessary.
> If the latter, can you configure Tor to use more than one middle relay node, depending on your threat model?
Tor makes dozens of circuits in a typical use. You never stick to a single circuit. In the Tor Browser you have first party stream isolation so you get a different circuit (and hence different middle and exit nodes) for each first party domain that you visit.
KAX17 also employed middle relays. It's not out of the question that they are attacking onion services in some way, like the 2014 "relay early" attack.
For example, if you run a relay chosen as a guard for an onion service, there are a number of clever tricks (sending heavy traffic to the onion service + observing which IP suddenly has lots of activity + eliminating other relay IPs) that can be done to find the IP of an onion service. There are also "sniper" DDoS attacks that can force an onion service to use your node as a guard. I would imagine that many or most onion operators haven't bothered to enable the Vanguard addon that makes this attack a little more expensive.
I really wonder about the feasability of keeping onion service IPs globally secret. It may not be possible. I would certainly not stake my freedom on it. End user traffic to onion services is considerably harder to compromise, though.
> I really wonder about the feasability of keeping onion service IPs globally secret. It may not be possible. I would certainly not stake my freedom on it.
Me either. KAX17 is visible. There are exceptionally well-resourced organizations with I think the motivation to unmask a seemingly target-rich collection of users, and the money and skill to simply infiltrate most relays, probably without being noticed.
I also wouldn't stake my freedom on it because it is simple to detect that you are using Tor, and that puts you in a tiny group, one that is (again) seemingly target-rich.
given that running Tor relay (god forbid - node) is risky for a regular citizen, i suspect that majority of Tor is run these days by the ones immune to such risks, ie. the law enforcement (and the ones made to collaborate). In such a situation the correlation should be pretty easy.
While running exit nodes definitely seems undesirable due to the volume of abusive traffic that is likely to go through the exit node, I bet other kinds of relays would be a lot less cumbersome. Obviously a very well-funded attacker will always have the upper hand, and obviously, if you were to always use your own node as the guard node, it would lose some of the properties of Tor, but I bet it wouldn't hurt for more of us to run nodes. I am interested.
Readit News
I suggest a complete end-to-end rethink of how anonymous Internet services are done. Instead of it being a tunnel for generic traffic, think of a specialised private protocol for input/output of information. Throw away the highly complex, insecure HTML5 that most hidden services are interacted through. Instead of slow, bloated HTTP requests, think of sockets that stay alive meaning traffic can be high bandwidth and low latency. We could even throw in some modern cryptography like ED25519 which would give some performance benefit. I had an idea for 'heartbeat groups' too which would prevent timing attacks at the ISP/wider Internet level.
If it weren't for the fact that I have a full time job and don't want the Five Eyes on me, I'd build it myself.
> I suggest ...
And what exactly qualifies you to make those statements? Especially since what follows IMO reads rather bizarre.
> I had an idea for 'heartbeat groups' too which would prevent timing attacks...
Great! What is this supposed to be? Is it some kind of mixing scheme? How does this prevent timing attacks? How did you model this to verify those claims you make? Do you have a publication on that somewhere?
> If it weren't for the fact that I have a full time job and don't want the Five Eyes on me, I'd build it myself.
In other words, you know better than the people who did the existing implementation, but really can't be bothered right now?
You got me a bit curious, but since you have no description or website link in your profile and a Google search for your nick only leads me back here, I started browsing through your comments, trying to find some details on your background in IT-security. Besides a bunch of strong opinions on practically every topic thrown at you, I didn't manage to dig up anything interesting so far.
Somewhere in your early comments, you said, your work entails managing bare metal machines. Somewhere else you said your job is basically skim reading docs. There are some other references to systems administration topics as well. Are you by any chance some kind of data center sysadmin?
I'm sorry and I'll gladly stand corrected, but for now there are simply too many red flags here for my taste.
I've wanted to reinvent hidden services for years and you're wrong about it being a matter of motivation. It really is a matter of both time and not wanting to bring attention to myself.
Yes, the idea of 'heartbeat groups' is as you described. Another reply linked this which sounds very similar: https://en.wikipedia.org/wiki/Chaffing_and_winnowing
I attacked an inanimate software project out of dissatisfaction and you attacked me. That isn't justified.
https://www.theguardian.com/world/2013/oct/04/nsa-gchq-attac...
Give us some more implementation details and whatnot and someone might implement it.
Javascript also has nothing to do with these attacks. Even if you turn off Javascript, KAX17 can still attempt end-to-end correlation attacks. This is much scarier than a Javascript browser exploit.
"In autumn 2019 I stumbled on something odd: Tor relays doing something that the official tor software is unable to do." [1]
[1] https://nusenu.medium.com/the-growing-problem-of-malicious-r...
The OP alludes to this:
"... and the fact that someone runs such a large network fraction of relays “doing things” that ordinary relays can not do (intentionally vague), is enough to ring all kinds of alarm bells."
... and the OP is "intentionally vague".
I, also, am very interested to know how they correlated them and what the interesting behavior was that they exhibited ...
> Some of KAX17's relays initially had used that email address in their ContactInfo but soon after these relays were setup the email address got removed from their configuration.
If I had endless resources and was truly paranoid, what I'd do is build my set of public guard nodes, make sure they're serving Tor traffic, etc. But then, I'd "borrow" those IPs occasionally for trusted nodes which will only accept connections from me (ideally both sets of machines will be live and routing traffic simultaneously).
In theory, you could apply the same tricks with similar success to exit nodes of course (though as usual, running an exit node is generally a slightly riskier / harder thing to do)
If they do all you've done is made the middle mode the guard.
That's not how Tor nodes work. Once you setup a guard node (and it got enough reputation) you won't be the only person using the guard node. Also de-anonymization attacks require you to know the traffic coming to the guard node (and if you run a trustworthy one yourself and you're not dealing with a global passive adversary then there's no way the attacker will be able to see the incoming traffic to the guard node).
That's not how Tor nodes work. Once you setup a guard node (and it got enough reputation) you will NOT be the only person using it.
Does an attacker only need to control the guard and exit nodes, or the middle relay node(s) as well?
If the latter, can you configure Tor to use more than one middle relay node, depending on your threat model?
Could Tor do something like overlay a fixed-throughput circuit-switched network on top of the packet-switched network to prevent correlation attacks? Obviously at the expensive of efficiency.
Also: If KAX17 is running nodes on 50+ AS's "including non-cheap cloud hosters like Microsoft" shouldn't it just take one insider at one of those hosts to leak the identity of one or more of these node operators? Come on, guys...
No, only controlling the guard and exit nodes is necessary.
> If the latter, can you configure Tor to use more than one middle relay node, depending on your threat model?
Tor makes dozens of circuits in a typical use. You never stick to a single circuit. In the Tor Browser you have first party stream isolation so you get a different circuit (and hence different middle and exit nodes) for each first party domain that you visit.
If you use bridges they take the place of a guard node and you will want to share otherwise it’s easy for an observer to associate inputs and outputs.
Using a vpn to connect to a bridge can provide some additional protection of your origin IP even if your bridge/guard mode is discovered.
Deleted Comment
For example, if you run a relay chosen as a guard for an onion service, there are a number of clever tricks (sending heavy traffic to the onion service + observing which IP suddenly has lots of activity + eliminating other relay IPs) that can be done to find the IP of an onion service. There are also "sniper" DDoS attacks that can force an onion service to use your node as a guard. I would imagine that many or most onion operators haven't bothered to enable the Vanguard addon that makes this attack a little more expensive.
I really wonder about the feasability of keeping onion service IPs globally secret. It may not be possible. I would certainly not stake my freedom on it. End user traffic to onion services is considerably harder to compromise, though.
Me either. KAX17 is visible. There are exceptionally well-resourced organizations with I think the motivation to unmask a seemingly target-rich collection of users, and the money and skill to simply infiltrate most relays, probably without being noticed.
I also wouldn't stake my freedom on it because it is simple to detect that you are using Tor, and that puts you in a tiny group, one that is (again) seemingly target-rich.