FTP seems broken

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]

changed milestone to %Tor: unspecified

added component::core tor/tor milestone::Tor: unspecified priority::high resolution::fixed status::closed type::task labels

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

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

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

Trac:
Description: 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]

to

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]
Priority: minor to major
Component: Torbutton to TorBrowserButton
Keywords: N/A deleted, N/A added
Actualpoints: N/A to N/A
Parent: N/A to N/A
Milestone: N/A to N/A
Points: N/A to N/A

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.

Trac:
Type: defect to task

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

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.

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

If we are going to close #3290 (moved), 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.

Trac:
Version: 1.2.4 to N/A
Component: TorBrowserButton to Tor Check

Trac:
Component: Tor Check to Tor Client

Hello guys, any updates on this? Thanks!!

Trac:
Username: supercyborg

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.

Trac:
Status: new to needs_information
Milestone: N/A to Tor: unspecified

3 months should be enough to comment here

Trac:
Status: needs_information to closed
Resolution: None to user disappeared

Trac:
Component: Tor Client to Tor

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.

Trac:
Status: closed to reopened
Resolution: user disappeared to N/A

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.

Trac:
Username: 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.

Trac:
Username: bitbeetle