Opened 8 years ago

Last modified 10 months ago

#2667 new defect

Exits should block reentry into the tor network

Reported by: mikeperry Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.7
Severity: Normal Keywords: needs-proposal, tor-relay, SponsorU-deferred
Cc: adrelanos@…, eyv@… Actual Points:
Parent ID: Points: medium/large
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (51)

comment:1 Changed 8 years ago by arma

Not a very effective fix -- they could use a Tor bridge, or an open proxy and direct it back into Tor, as their destination. It seems hard to fix this one. Does that make your fix worth doing as a tiny step, or not worth doing because it increases code complexity for not enough gain?

comment:2 Changed 8 years ago by mikeperry

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?

comment:3 Changed 8 years ago by mikeperry

Is there any reason why bridges should allow exits to connect to them, though?

We might be able to cut that loop out on their side, since they have the consensus too. At least until we start doing IP forwarding-based bridges...

comment:4 Changed 8 years ago by nickm

Milestone: Tor: unspecified

comment:5 Changed 7 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.3.x-final
Priority: normalmajor

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.

comment:6 in reply to:  5 ; Changed 7 years ago by 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.

comment:7 in reply to:  6 Changed 7 years ago by nickm

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.

comment:8 Changed 7 years ago by arma

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). 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.

comment:9 in reply to:  8 Changed 7 years ago by rransom

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.

comment:10 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: 0.2.4.x-final
Priority: majorcritical

comment:11 Changed 7 years ago by arma

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.

comment:12 Changed 7 years ago by 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 you'd be prevented from using your own Tor client.

comment:13 in reply to:  12 ; Changed 7 years ago by 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 you'd be prevented from using your own Tor client.

Hrmm. This sounds like something we can solve with a tweak to the #2905 language. I updated #5611 to suggest it.

comment:14 Changed 7 years ago by mikeperry

Scratch that, #5611 will be a Tails/Linux solution only. I created #5658 for Vidalia.

comment:15 in reply to:  13 ; Changed 6 years ago by 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 you'd be prevented from using your own Tor client.

Hrmm. This sounds like something we can solve with a tweak to the #2905 language. I updated #5611 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.

comment:16 in reply to:  15 Changed 6 years ago by proper

Cc: adrelanos@… added

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.)

comment:17 in reply to:  15 ; Changed 6 years ago by proper

Replying 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.

comment:18 in reply to:  15 Changed 6 years ago by mikeperry

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 you'd be prevented from using your own Tor client.

Hrmm. This sounds like something we can solve with a tweak to the #2905 language. I updated #5611 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?

comment:19 Changed 6 years ago by nickm

Keywords: needs-proposal added

comment:20 Changed 6 years ago by nickm

Keywords: tor-relay added

comment:21 Changed 6 years ago by nickm

Component: Tor RelayTor

comment:22 Changed 6 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

comment:23 Changed 5 years ago by eyv

Cc: eyv@… added

comment:24 Changed 5 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???
Priority: criticalmajor

comment:25 in reply to:  17 Changed 4 years ago by cypherpunks

Replying to proper:

[...]
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.

This would be true, except the discussion above suggests also having bridges refuse inbound connections from known exits.

Replying to mikeperry:

[...]
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?

I guess you're assuming the browser user is also the administrator of the transparent proxy? In some configurations, this isn't the case. Imagine someone wants to offer free wifi but doesn't want wifi users to be able to see what their internet upstream is. This configuration is possible (and deployed in some places), but if this proposal were implemented it would stop working. This configuration is useful in places like Germany where most people are afraid of the liability of having open wifi.

comment:26 Changed 4 years ago by nickm

Milestone: Tor: 0.2.???Tor: 0.2.7.x-final

These may be worth looking at for 0.2.7.

comment:27 Changed 4 years ago by nickm

Status: newassigned

comment:28 Changed 4 years ago by s7r

For the relays, it's better to make Tor automatically reject exiting *to* the IPs in the consensus and not refuse the requests *from* the IP addresses in the consensus (most important argument Sebastian's comment 6). Exit relays are used also in rendezvous circuits, but it shouldn't matter since we are talking about the exit policy and not behavior in Tor circuits.

For the bridges, the only way is to refuse requests from the IP addresses in the consensus, but just the ones with accept policy in the descriptor. A bridge should not care about the Exit flag, because there are relays in the consensus which permit exiting to very few ports and do not have the Exit flag. These relays have a chance to reach a bridge, if it's listening on the right port.

Either way, for bridges is little bit more complicated. It will make it a lot easier for some censors.

Take for example a network where everyone (maybe behind NAT or not) uses a proxy which filters a lot of things and bans a lot of destinations. Obviously all IP addresses in Tor network consensus are blacklisted too, so these people can only use bridges (with PTs if the censor is also fingerprinting traffic). In this case, the censor will not need to hunt the bridges in bridge-db (which we try to make so hard), censor can just setup a relay on the proxy server IP with lowest possible speed (useless for the Tor network) and be sure nobody in their network can connect to Tor. Same applies to NAT, where everyone has a single public IP address - the proxy example is often seen in practice, especially in companies / workplaces even in non-censored countries. Some people won't be able to use Tor at work then. This maybe doesn't sound like a terrible issue, but a while ago a journalist (at least that's what he said he was) asked me on irc to help him setup a private bridge on a vps which he can use at work to keep his sources safe and hidden (competition between employees, curious senior editors or managers maybe). Tor network was banned at proxy end at his workplace. He could use any bridge from bridge-db, wanted a dedi one for unknown / unrelated reasons.

Censored countries also sometimes use a system similar to the one above. Bridges will not annoy as much as now these censors. A really insane ISP (in an insane country) could even hijack one port from all IP addresses they control and setup low speed useless relays on all, so nobody in their network can use bridges. This is a little bit exaggerated and unlikely, but not impossible in theory. Already doing DPI and advanced active traffic fingerprinting, what would cost them more to try this attack. It will cost the directory authorities a lot more.

This should be implemented only if there are more gains than looses. Is Tor over Tor a threat big enough so an unknown number of bridge users can be sacrificed?

If this is merged, it should be the default behavior, no option in torrc to turn it off. If it can be turned off or it's not the default behavior it means it's not a threat serious enough to risk sacrificing an unknown number of bridge users. Implementing it just for relays and not for bridges would not make sense either.

comment:29 in reply to:  28 ; Changed 4 years ago by isis

Replying to s7r:

For the relays, it's better to make Tor automatically reject exiting *to* the IPs in the consensus and not refuse the requests *from* the IP addresses in the consensus (most important argument Sebastian's comment 6).


This would break so many things! Perhaps you meant reject exiting to IP:ORPorts?

comment:30 in reply to:  29 Changed 4 years ago by s7r

Replying to isis:

Replying to s7r:

For the relays, it's better to make Tor automatically reject exiting *to* the IPs in the consensus and not refuse the requests *from* the IP addresses in the consensus (most important argument Sebastian's comment 6).


This would break so many things! Perhaps you meant reject exiting to IP:ORPorts?

Indeed, very important highlight. Was focusing on stream direction (to/from) and didn't go too much in details.

comment:31 Changed 4 years ago by nickm

Keywords: 027-triaged-1-in added

Marking some tickets as triaged-in for 0.2.7 based on early triage

comment:32 Changed 4 years ago by isabela

Keywords: SponsorU added
Points: medium/large
Priority: majornormal
Version: Tor: 0.2.7

comment:33 Changed 3 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.8.x-final

comment:34 Changed 3 years ago by nickm

Keywords: SponsorU removed
Sponsor: SponsorU

Bulk-replace SponsorU keyword with SponsorU field.

comment:35 Changed 3 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.???

It is impossible that we will fix all 252 currently open 028 tickets before 028 releases. Time to move some out. This is my first pass through the "assigned" tickets with no owner, looking for things to move to ???.

If somebody thinks they can get these done before the 0.2.8 timeout, please assign it to yourself and move it back?

comment:36 Changed 3 years ago by isabela

Sponsor: SponsorUSponsorU-can

comment:37 Changed 3 years ago by nickm

Parent ID: #2664#17293

comment:38 Changed 3 years ago by nickm

Keywords: SponsorU-deferred added
Sponsor: SponsorU-can

Remove the SponsorU status from these items, which we already decided to defer from 0.2.9. add the SponsorU-deferred tag instead in case we ever want to remember which ones these were.

comment:39 Changed 3 years ago by nickm

Parent ID: #17293

comment:40 Changed 2 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:41 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:42 Changed 19 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:43 Changed 19 months ago by nickm

Keywords: 027-triaged-in added

comment:44 Changed 19 months ago by nickm

Keywords: 027-triaged-in removed

comment:45 Changed 19 months ago by nickm

Keywords: 027-triaged-1-in removed

comment:46 Changed 19 months ago by nickm

Status: assignednew

Change the status of all assigned/accepted Tor tickets with owner="" to "new".

comment:47 Changed 12 months ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

comment:48 Changed 11 months ago by arma

I continue to think that teaching exit relays to avoid allowing exit connections to known relays (IP:ORPort) is a good and useful step.

We keep running across messy situations where letting somebody connect to a relay from an exit relay's IP address turns into a security surprise.

comment:49 in reply to:  5 ; Changed 11 months ago by arma

Replying to nickm:

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.

Nick, has the world gotten any better since this comment six years ago? Assuming no, how much work do you think this hashmap would be? :)

comment:50 in reply to:  49 Changed 11 months ago by nickm

Replying to arma:

Replying to nickm:

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.

Nick, has the world gotten any better since this comment six years ago? Assuming no, how much work do you think this hashmap would be? :)

About a day's work.

comment:51 Changed 10 months ago by dgoulet

Nickm's attempt at having an interface to store IP addr with bloom filter: address_set_029

Note: See TracTickets for help on using tickets.