Opened 9 years ago

Last modified 10 months ago

#3290 new enhancement

Design some way to ensure circuit reuse for FTP (and other?) multi-connection protocols

Reported by: supercyborg Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client needs-design needs-insight
Cc: intrigeri, proper Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Some protocols, such as FTP (in passive mode) use 2 connections, one for control and a second one for data. Smarter FTP servers will not allow a data connection coming from an IP different than the control connection.

Could an enhancement be made so that TOR recognizes an already established control connection to a particular IP on port 21 (in the case of FTP), and then reuses the same circuit on which that control connection was established to establish the data connection (if to the same IP)? This would make both connections appear as coming from the same IP/exit-node and not make the FTP server suspicious.

Of course, this behavior could be disabled by default (to keep current behavior) and enabled from the config file (a directive like ReuseCircuitsForSameHostConnections).

This would greatly enhance usability of FTP over TOR, which otherwise works fine if such behavior happens "accidentally" (effectively no more than 1 in 5 or 6 times, because of the number of established circuits, 5 or 6, and TOR's randomness in assigning circuits to new connections)

Sorry if this has already been addressed, I couldn't find any information on whether or not it has been.

Child Tickets

Change History (7)

comment:1 Changed 9 years ago by rransom

Component: - Select a componentTor Client
Resolution: duplicate
Status: newclosed

Duplicate of #1259.

comment:2 Changed 8 years ago by nickm

Keywords: tor-client added

comment:3 Changed 8 years ago by nickm

Component: Tor ClientTor

comment:4 Changed 6 years ago by intrigeri

Cc: intrigeri added

I get why #1259 was closed (TrackHostExits is a working workaround), but it seems to me that this very ticket was about a better solution, that doesn't require users to tweak torrc by hand. So, I don't get why it was closed too. Should I reopen it?

comment:5 Changed 6 years ago by nickm

Milestone: Tor: unspecified
Resolution: duplicate
Status: closedreopened

I think this is the kind of thing that would best be done with explicit configuration or application-level hinting as suggested in proposal 229. Or maybe we could tweak the behavior of one of the really fine-grained circuit isolation modes so that eg use of the same socks username/password could count as instructions to

But I don't think we would want to have a general rule saying "always use the same circuit for a given IP if you already have a connection that's using that IP." It seems there's probably some way to exploit that to track clients across websites when you otherwise wouldn't be able to.

In any case, there's no reason not to look for a better way to do this. So, reopening and assigning the unspecified milestone.

comment:6 Changed 3 years ago by nickm

Keywords: needs-design needs-insight added; FTP removed
Priority: MediumLow
Severity: Normal
Status: reopenednew
Summary: Circuit reuse for FTP (and other?) multi-connection protocolsDesign some way to ensure circuit reuse for FTP (and other?) multi-connection protocols

So, right now we have a way to tell Tor, via the mechanisms of proposal 171, that two streams should _not_ be put on the same circuit ... but not to say that two streams _should_ be put on the same circuit. We'd need a design proposal to provide that kind of application-level hinting.

edit: fixed proposal number

Last edited 3 years ago by nickm (previous) (diff)

comment:7 Changed 10 months ago by gk

Cc: proper added

Resolving #9211 as duplicate.

Note: See TracTickets for help on using tickets.