Exits should block reentry into the tor network
With proposal 110, we blocked the ability of Tor clients to use the Tor protocol for an unbounded amplification attack to destroy the Tor network. However, we still have not completely prevented this attack. It is still possible to tunnel tor over tor by using exits to connect back to other tor nodes. This property can still be used to execute the unbounded amplification attack on the Tor network, or just on the tor directory authorities.
One fix for this would be to add code to exit nodes to implicitly add all of the IP + ORport combinations of all other relays to their exit policy reject lines, or otherwise block this connection at some other level.
Activity
changed milestone to %Tor: unspecified
I think it still makes this worth while. If the adversary has to now use bridges and proxies, we've still imposed a bound on their resources, even if it if it is a very high bound. Proxies are not very stable, and bridges are designed to be hard to obtain in unlimited quantity.
The attack would go from requiring just a modem to destroy the tor network to requiring a modem + enough stable proxy and bridge bandwidth to destroy it. I think this is an improvement.
Of course, it depends on how hard this is to implement. I suspect that it should just be a day or two of hacking, at most, right?
Given recent upswings in the popularity of DOS attacks, I think we should plan to do this one for 0.2.3. Specifically:
- Exits should block connections to known Tor ORPorts.
- Bridges (and relays?) should refuse OR connections from exit IPs.
- Both of these behaviors should be configured via torrc and on-by-default.
The only implementation challenge here will be doing efficient lookup of nodes by address or address:port. (My intuition is that a linear search here will be too expensive.) We can do that by adding another hashmap to node_t.
Trac:
Priority: normal to major
Milestone: Tor: unspecified to Tor: 0.2.3.x-final-
Replying to Sebastian:
Replying to nickm:
- Bridges (and relays?) should refuse OR connections from exit IPs.
The "and relays" part worries me. That means you don't get to use Tor if anyone using the same IP address as you is in the consensus as an Exit node.
Good point. Let's say then that only bridges should do that.
I started out thinking that the "exits should block connections back into the network" was a great idea, but the "bridges should refuse connections from exits" was a poor idea since it prevents people sharing an IP address with an exit relay from using bridges.
But on further thought, I think that's an acceptable tradeoff: if you're the sort of place that needs a bridge, hopefully you're not the sort of place that runs an exit.
This gets messier when we think about the concrete example of Syria though. We have a lot of users in Syria, and some of them click 'share' sometimes. We plan to make it easier to badexit those relays (#4207 (moved)). But bridges in this case should ignore the badexit flag when deciding whether to hang up on a connection from an exit relay's IP address. So you can't use a bridge if the guy sitting near you in the Internet cafe three hours ago clicked 'share'? That's sad.
Also, I note that multihomed exits are another unhandled edge case here.
Replying to arma:
Also, I note that multihomed exits are another unhandled edge case here.
Exits in the Amunet family have sent outbound traffic on an IP address which does not have an ORPort on it before. They may still do that.
But making bridges refuse connections from exits guarantees that bridges which require AUTHORIZE cells cannot perform automatic reachability tests until relays learn to EXTEND using bridge passwords. And we don't really want a bridge to have to give away its password for that purpose.
-
Jake and I realized at 28c3 that implementing this feature would make Tor clients mysteriously fail to work on a network that is transparently torified. So in fact on such networks you are forced to trust the network and its communal Tor client? That is a sad side effect. Not that using Tor on a transparently torified network would be much fun performance-wise.
-
A specific example of such a network is the open torified wireless that some variations of the Torouter expect to offer, where a) it's open wireless so people get to watch it, and b) because of #2667 (moved) you'd be prevented from using your own Tor client.
-
Replying to arma:
A specific example of such a network is the open torified wireless that some variations of the Torouter expect to offer, where a) it's open wireless so people get to watch it, and b) because of #2667 (moved) you'd be prevented from using your own Tor client.
Hrmm. This sounds like something we can solve with a tweak to the #2905 (closed) language. I updated #5611 (moved) to suggest it.
-
Scratch that, #5611 (moved) will be a Tails/Linux solution only. I created #5658 (closed) for Vidalia.
-
Replying to mikeperry:
Replying to arma:
A specific example of such a network is the open torified wireless that some variations of the Torouter expect to offer, where a) it's open wireless so people get to watch it, and b) because of #2667 (moved) you'd be prevented from using your own Tor client.
Hrmm. This sounds like something we can solve with a tweak to the #2905 (closed) language. I updated #5611 (moved) to suggest it.
I'm not following. The problem is that we'd prevent people behind a Torified network from running their own Tor client. At the same time we tell them that if they really want to be secure, they should run their own Tor client. I think our advice is correct.
I wonder if the better fix is to make the "transparent torify" process smarter (that is, write and maintain some "best practices" iptables rules that do the right thing), so it can recognize connections to the Tor network and let them through directly? It seems risky (full of opportunities for serious fail), but better than the other options I've heard so far.
To make this worse:
- if you forbid reentry into the Tor network...
- A good way to censor and monitor Tor users would be...
- Put your network behind a transparent torified network.
- Connect to nodes under your control.
I wonder if the better fix is to make the "transparent torify" process smarter (that is, write and maintain some "best practices" iptables rules that do the right thing), so it can recognize connections to the Tor network and let them through directly? It seems risky (full of opportunities for serious fail), but better than the other options I've heard so far.
Please don't. The advantage of an correctly transparently torified network is, that there can be no IP/DNS leaks. If you allow some magic direct connections, transparent proxying will only be a usability feature, no security feature.
If you really must... Please make it configurable thought an torrc option.
TRANS_PORT_ALLOW_DIRECT_CONNECTIONS_TO_THE_TOR_NETWORK=1 (Find better name. Default is 1. 0 disables the magic direct Tor network connection feature.)
Trac:
Cc: N/A to adrelanos@riseup.netReplying to arma:
The problem is that we'd prevent people behind a Torified network from running their own Tor client. At the same time we tell them that if they really want to be secure, they should run their own Tor client. I think our advice is correct.
Alternative solution: Advice users behind transparently torified networks to use bridges. This should be a sensible workaround?
The Tor exit does not have the list of all bridges and can therefore not block reentry into the Tor network. And the Tor user is supposed not have large quantities of bridges.
-
Replying to arma:
Replying to mikeperry:
Replying to arma:
A specific example of such a network is the open torified wireless that some variations of the Torouter expect to offer, where a) it's open wireless so people get to watch it, and b) because of #2667 (moved) you'd be prevented from using your own Tor client.
Hrmm. This sounds like something we can solve with a tweak to the #2905 (closed) language. I updated #5611 (moved) to suggest it.
I'm not following. The problem is that we'd prevent people behind a Torified network from running their own Tor client. At the same time we tell them that if they really want to be secure, they should run their own Tor client. I think our advice is correct.
Hrmm.. For traffic analysis resistance against attacks like website fingerprinting, it's been shown to be better to share a single tor client to perform concurrent activity. On the other hand, the only advantage that I'm aware of with having your own local Tor client is the ability to do "New Identity" and have it give you a new circuit.
Can you explain why asking people if they are behind a Tor transproxy doesn't work? These people should be a small minority...
What if proper provides those people with alternate TBB launch scripts that allow them to launch Tor Browser without a local tor client, and optionally specify the control port and password for their upstream Tor client's control port?