Opened 10 years ago

Closed 7 years ago

#1259 closed task (fixed)

FTP seems broken

Reported by: mikeperry Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: mikeperry, Sebastian, bitbeetle@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by mikeperry)

Despite the fact that we tell Firefox to use SOCKS for FTP, it appears as if it is broken. This probably is a
firefox bug, but filing it anyway to remind myself to look deeper into it later. I should test this with an
ssh socks proxy and see what happens.

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (22)

comment:1 Changed 10 years ago by mikeperry

This may be a side effect of the SOCKS timeout issue.

I tested Firefox+Torbutton+SSH socks proxy vs Firefox+Torbutton+Tor socks proxy and the SSH proxy worked, Tor did not.

I also looked into setting Firefox into passive mode, which apparently is the only mode Firefox supports..

comment:2 Changed 10 years ago by mikeperry

We could try Fireftp (https://addons.mozilla.org/en-US/firefox/addon/684) to see if it behaves any better.

comment:3 Changed 8 years ago by mikeperry

Component: TorbuttonTorBrowserButton
Description: modified (diff)
Priority: minormajor

This may actually work now in TorBrowser. Upping priority as a reminder to test.

comment:4 Changed 8 years ago by arma

wanoskarnet points out that the ftp protocol may be not as compatible with tor as we might like. With passive mode, you end up making another connection to the ftp server. What if that other connection comes from a different circuit than the first? A properly behaving ftp server should be suspicious.

I wonder how networks like aol (which keep rotating you around IP addresses too) deal with that issue. Probably by handling it specially on their nat.

comment:5 Changed 8 years ago by arma

Type: defecttask

comment:6 Changed 8 years ago by nickm

See also #3290 for some analysis and suggestions on this.

comment:7 Changed 8 years ago by Sebastian

I'm thinking that TrackHostExits might be a viable workaround here. It would seem that you typically don't need to ftp to that many different sites, so setting it for the individual sites would work - or a second tor instance could be used.

comment:8 Changed 8 years ago by arma

Should this trac entry move to the 'Tor client' component?

comment:9 Changed 8 years ago by mikeperry

Component: TorBrowserButtonTor Check
Version: 1.2.4

If we are going to close #3290, yes.

Sadly, it looks like TrackHostExits cannot apply to ports.. We probably need two ways to specify ports:

  1. *:port - All requests to port should attempt to use the same exit IP.
  2. ?:port - All requests to pairs of (IP, port) should use the same exit IP.

Or, we could just implement Robert Hogan's version of Proposal 171 for auto-newnyming on different ports. Supposedly a patch exists for that somewhere right now (does it have a ticket?)

Robert's patch might not enforce the use of the same exit IP by default though.. He may have written it to only concern itself with using a new circuit on new ports.

comment:10 Changed 8 years ago by mikeperry

Component: Tor CheckTor Client

comment:11 Changed 8 years ago by supercyborg

Hello guys, any updates on this? Thanks!!

comment:12 in reply to:  11 Changed 8 years ago by mikeperry

Replying to supercyborg:

Hello guys, any updates on this? Thanks!!

Do you have an example FTP site that is broken? And are we correct in our guess that it is circuit-switching that is causing the problem? Does TrackHostExits fix it for you?

All we have are guesses at this point and it is hard to devote resources to fixes based on guesses. It often ends up wasting time.

comment:13 Changed 8 years ago by nickm

Milestone: Tor: unspecified
Status: newneeds_information

comment:14 Changed 8 years ago by Sebastian

Resolution: Noneuser disappeared
Status: needs_informationclosed

3 months should be enough to comment here

comment:15 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:16 Changed 7 years ago by proper

Resolution: user disappeared
Status: closedreopened

I have an example sites, which are broken.

Broken in Tor Browser: ftp://ftp.gnu.org/gnu/alive/alive-2.0.0.tar.xz
www download working: http://ftp.gnu.org/gnu/alive/alive-2.0.0.tar.xz (Just for the sake of a good test example.)

Broken in Tor Browser: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/16.0/linux-i686/ach/firefox-16.0.tar.bz2
www download working: https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/16.0/linux-i686/ach/firefox-16.0.tar.bz2

ftp link, broken in wget: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/16.0/MD5SUMS
www link working: https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/16.0/MD5SUMS

Broken using torsocks:

--2012-10-22 14:17:59--  ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/16.0/MD5SUMS
           => `MD5SUMS'
Resolving ftp.mozilla.org (ftp.mozilla.org)... 63.245.215.46
Connecting to ftp.mozilla.org (ftp.mozilla.org)|63.245.215.46|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD (1) /pub/mozilla.org/firefox/releases/16.0 ... done.
==> SIZE MD5SUMS ... 262264
==> PASV ... 14:18:30 libtorsocks(10633): SOCKS V5 connect failed: 14:18:30 libtorsocks(10633): TTL Expired
couldn't connect to 63.245.215.46 port 52584: Connection timed out
Retrying.

Broken behind a transparent proxy:

/usr/bin/wget --passive-ftp ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/16.0/MD5SUMS
--2012-10-22 14:16:29--  ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/16.0/MD5SUMS
           => `MD5SUMS'
Resolving ftp.mozilla.org (ftp.mozilla.org)... 63.245.215.46
Connecting to ftp.mozilla.org (ftp.mozilla.org)|63.245.215.46|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD (1) /pub/mozilla.org/firefox/releases/16.0 ... done.
==> SIZE MD5SUMS ... 262264
==> PASV ... done.    ==> RETR MD5SUMS ... 
Error in server response, closing control connection.
Retrying.

comment:17 Changed 7 years ago by bitbeetle

Setting 'TrackHostExits ftp.mydomain.tld' in ~/.torrc fixed ftp for me. This is a great workaround.

PLEASE BE AWARE that ftp sends your password in plaintext and my understanding is that your exit node will gain full access to your ftp server unless you use one of the TLS extensions to ftp.

Of course, it would be great if tor did this more intelligently to correlate these transactions less. E.g., enabling a specific flag to temporarily track exit nodes for a host that is accessed on port 21 with a timeout.

comment:18 Changed 7 years ago by bitbeetle

Update, sorry, TrackHostExits does not work. When it does work, FTP works fine ... but after a while Tor 0.2.3.25 (git-3fed5eb096d2d187) ignores it for me and again opens data connections on separate circuits than the control connection. Using IP instead of hostname (since data connections are opened via ip from server), connecting only via IP, HUPping tor, does not resolve it. This is unfortunate. Restarting tor temporarily fixes it, but it soons breaks again.

comment:19 Changed 7 years ago by bitbeetle

Cc: bitbeetle@… added

Woop again. TrackHostExits does work. Need to set the ip address rather than the host. Vidalia prevents reloading the service from rechecking ~/.torrc .

comment:20 Changed 7 years ago by bitbeetle

I suck! Totally still only works for a while then dies again. TrackHostExits in ~/.torrc seems broken.

comment:21 Changed 7 years ago by bitbeetle

I super suck! TrackHostExits works great. Obviously ~/.torrc doesn't work if tor is not running as my user. /etc/tor/torrc is the way to go.

comment:22 Changed 7 years ago by nickm

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.