On Mon, 22 Aug 2022, Bogus User wrote:

(can't really use ftp over Tor)

On Wed, 24 Aug 2022, James Tomasino wrote:

FTP would be no different. Just need to handle port 22. :)

Port 22 is normally for SSH, not FTP though.

That would be more like port 21 (FTP control),
as well as port 20 and other high-numbered ports that the server
is configured to use (FTP data). Tor will gladly _transport_ those,
whether you're using Tor at client side, or Tor hidden service
on the server side.

But the real problem is modern "security feature"
that is enabled in many FTP servers today:
such servers would *reject* passive data connection
which it perceived as not having originated from the same IP
as the control connection, even that it targeted a correct port.
Since under Tor, you usually don't have control over that,
you will run afoul of this issue.

Some servers (like GNU FTP server) are quite up-front about this,
while other servers, in my experience, would just silently ignore the
"wrong" data connection and the control side would appear being "hang" without giving you any clue on what went wrong. This is what a
command line passive FTP session would look like, when connected using Tor and the server was up-front about the issue:

$ torify ftp -n ftp.gnu.org
Connected to 209.51.188.20.
220 GNU FTP server ready.
530 Please login with USER and PASS.
530 Please login with USER and PASS.
SSL not available

user anonymous

[...]

Remote system type is UNIX.
Using binary mode to transfer files.

passive

Passive mode on.

ls

227 Entering Passive Mode (209,51,188,20,117,15).
425 Security: Bad IP connecting.

quit

221 Goodbye.
$

My take is using FTP over Tor (at least from client side) is doable,
but the server ought not to enable this "security feature";
which the easiest way to ensure that is probably operating
such FTP server yourself, dedicated for this use.

This problem is in no way specific to Tor. In fact, I have run afoul
and discovered the details around this, not from my experience as Tor user, but rather as someone who tried to use FTP(S) today from inside multi-homed network with NAT/PAT + dumb load-balancer.

For FTP as Tor hidden service, I have no experience with ins and outs
around how hidden service gateway represent each client address to
the server software; so... I couldn't comment on that.

On Mon, 22 Aug 2022, Bogus User wrote:

BBS's were in many cases file exchange points,
I guess you need the web for that.

Actually, in today's pubnix/Tilde configuration, the file transfer
technology of choice would be SCP/SFTP; which comes with the SSH
server implementation in use. SSH (which underlies SCP/SFTP)
is a single-port single-connection protocol; it works with Tor.

This enables each user with account on the pubnic/Tilde in question
to upload/download files, including other users' files; when allowed
via Unix permission.

However, if you are also aiming for providing anonymous
file sharing/downloading front as well, it would fall a bit outside
the intended uses of SCP/SFTP; but it is doable by creating dummy `anonymous`/`guest` Unix user, with no password/authentication;
together with disabled shell login, all command executions,
all other subsystems, and port [reverse/]forwarding.
Somehow commercial hosting operators are so squeamish about this stuff;
not exacly sure why, so caveat emptor about security gotchas
that might exist.

On the "web" side of things, there are also multiple choices:

- HTTP(s) file drop, with bare POST/PUT endpoint similar to how things
like <http://0x0.st/> works; optionally with upload form.

- WebDAV: works on top of HTTP(s), provides PUT method support,
explicit directory listing, and allows more manipulation primitives
like moving/renaming, locking, and editing filesystem metadata.
Apache HTTP server comes with built-in WebDAV support,
which you can enable; and if Windows users matter to you,
this is also one of the few network file protocols that are supported
natively in Windows Explorer, apart from SMB and FTP.

Regards,
~xwindows


Note: This post is written in mobile-friendly RFC 3676
"text/plain; format=flowed; delsp=yes" way.
--
xwindows' gallery of freely-licensed artworks
https://tilde.club/~xwindows/ http://tilde.club/~xwindows/ gopher://tilde.club/1/~xwindows/
--- Synchronet 3.19a-Linux NewsLink 1.113

On Mon, 22 Aug 2022, Bogus User wrote:

(can't really use ftp over Tor)

On Wed, 24 Aug 2022, James Tomasino wrote:

FTP would be no different. Just need to handle port 22. :)

Port 22 is normally for SSH, not FTP though.

That would be more like port 21 (FTP control),
as well as port 20 and other high-numbered ports that the server
is configured to use (FTP data). Tor will gladly _transport_ those,
whether you're using Tor at client side, or Tor hidden service
on the server side.

But the real problem is modern "security feature"
that is enabled in many FTP servers today:
such servers would *reject* passive data connection
which it perceived as not having originated from the same IP
as the control connection, even that it targeted a correct port.
Since under Tor, you usually don't have control over that,
you will run afoul of this issue.

Some servers (like GNU FTP server) are quite up-front about this,
while other servers, in my experience, would just silently ignore the
"wrong" data connection and the control side would appear being "hang" without giving you any clue on what went wrong. This is what a
command line passive FTP session would look like, when connected using Tor and the server was up-front about the issue:

$ torify ftp -n ftp.gnu.org
Connected to 209.51.188.20.
220 GNU FTP server ready.
530 Please login with USER and PASS.
530 Please login with USER and PASS.
SSL not available

user anonymous

[...]

Remote system type is UNIX.
Using binary mode to transfer files.

passive

Passive mode on.

ls

227 Entering Passive Mode (209,51,188,20,117,15).
425 Security: Bad IP connecting.

quit

221 Goodbye.
$

My take is using FTP over Tor (at least from client side) is doable,
but the server ought not to enable this "security feature";
which the easiest way to ensure that is probably operating
such FTP server yourself, dedicated for this use.

This problem is in no way specific to Tor. In fact, I have run afoul
and discovered the details around this, not from my experience as Tor user, but rather as someone who tried to use FTP(S) today from inside multi-homed network with NAT/PAT + dumb load-balancer.

For FTP as Tor hidden service, I have no experience with ins and outs
around how hidden service gateway represent each client address to
the server software; so... I couldn't comment on that.

On Mon, 22 Aug 2022, Bogus User wrote:

BBS's were in many cases file exchange points,
I guess you need the web for that.

Actually, in today's pubnix/Tilde configuration, the file transfer
technology of choice would be SCP/SFTP; which comes with the SSH
server implementation in use. SSH (which underlies SCP/SFTP)
is a single-port single-connection protocol; it works with Tor.

This enables each user with account on the pubnic/Tilde in question
to upload/download files, including other users' files; when allowed
via Unix permission.

However, if you are also aiming for providing anonymous
file sharing/downloading front as well, it would fall a bit outside
the intended uses of SCP/SFTP; but it is doable by creating dummy `anonymous`/`guest` Unix user, with no password/authentication;
together with disabled shell login, all command executions,
all other subsystems, and port [reverse/]forwarding.
Somehow commercial hosting operators are so squeamish about this stuff;
not exacly sure why, so caveat emptor about security gotchas
that might exist.

On the "web" side of things, there are also multiple choices:

- HTTP(s) file drop, with bare POST/PUT endpoint similar to how things
like <http://0x0.st/> works; optionally with upload form.

- WebDAV: works on top of HTTP(s), provides PUT method support,
explicit directory listing, and allows more manipulation primitives
like moving/renaming, locking, and editing filesystem metadata.
Apache HTTP server comes with built-in WebDAV support,
which you can enable; and if Windows users matter to you,
this is also one of the few network file protocols that are supported
natively in Windows Explorer, apart from SMB and FTP.

Regards,
~xwindows


Note: This post is written in mobile-friendly RFC 3676
"text/plain; format=flowed; delsp=yes" way.
--
xwindows' gallery of freely-licensed artworks
https://tilde.club/~xwindows/ http://tilde.club/~xwindows/ gopher://tilde.club/1/~xwindows/
--- Synchronet 3.19a-Linux NewsLink 1.113

On Thu, 25 Aug 2022 14:22:21 +0700 (+07)
xwindows <xwindows@tilde.club> wrote:

However, if you are also aiming for providing anonymous
file sharing/downloading front as well, it would fall a bit outside
the intended uses of SCP/SFTP; but it is doable by creating dummy `anonymous`/`guest` Unix user, with no password/authentication;
together with disabled shell login, all command executions,
all other subsystems, and port [reverse/]forwarding.
Somehow commercial hosting operators are so squeamish about this
stuff; not exacly sure why, so caveat emptor about security gotchas
that might exist.

I did something like that once, back when I had decent internet
service for a different hair brained idea no one ever used...

It wasn't super easy, but it wasn't super difficult either. I wrote it
in python, (I forget the name of the library I used) and was able to
make it work, but at the end of it all no one used it and I didn't
really like the feel of it anyway.

I wanted a kind of file sharing experience, "archie for onion". It
just didn't catch on. (I had hoped to make a kind of federated
archiving setup, where people could add their servers to the mix and we
could have indexes, a lot like archie used to work) the reason I didn't
just use HTTP is because I wanted something people could easily upload
with, something they were likely to already have.

I wasn't comfortable forwarding Tor to my sshd, I wanted a separate
daemon, something that didn't have the capacity for shell access so
even if someone managed to break it, there was no shell to be had. The
project took me a few days to complete, and it turned out to be a
complete waste of time. No one was interested, I gave up. The code is
sitting on a computer that hasn't been powered up for years, and I'm
too lazy to fire it up. :-) But there are python libraries available to
do exactly what you're talking about. They just take a little coding.

FTP has some things that make it kind of interesting, the ability to
transfer files between two ftp servers without actually transferring
them to your own computer first seemed fascinating, but I don't think
I've ever heard of anyone using that. There are ftp daemon libraries
available that allow you to do stuff like make special directories, I
thought it would have been neat to make a "REST" style API over FTP.
Example, uploading email to a "magic directory" that forwards it.

Luckily, I found out that was a no-go over Tor before wasting too much
time with it.

I don't really like that ssh is encrypted, Tor already does that and if
you're going for old school, telnet/ftp are more authentic. (and secure,
at least over Tor) and if (back then) the goal was to revive archie, it
seemed like ftp would have been the logical choice.

But it's all very irrelevant if it isn't interesting to anyone else :-)



--- Synchronet 3.19a-Linux NewsLink 1.113

On 2022-08-26, Bogus User <bogus@example.invalid> wrote:

I don't really like that ssh is encrypted, Tor already does that and if you're going for old school, telnet/ftp are more authentic. (and secure,
at least over Tor) and if (back then) the goal was to revive archie, it seemed like ftp would have been the logical choice.

Maybe rlogin/rsh/rcp is what you're looking for.
--- Synchronet 3.19a-Linux NewsLink 1.113

On 25/08/2022 04:22, xwindows wrote:

HTTP(s) file drop, with bare POST/PUT endpoint similar to how things
like<http://0x0.st/> works; optionally with upload form.

This is so cool!
Do you know any other sites or ideas that provides this kind of thing?

For `this kind of thing` I mean delivering solutions using simple tools
such as a few endpoints and plain HTML just like 0x0.st is doing.

We should start a list of "services" like that.

I just saw that the url shortening was disabled, maybe I should create
one for fun next weekend.
--- Synchronet 3.19a-Linux NewsLink 1.113

On 2022-09-04, Jack <jacksonbenete@gmail.com> wrote:

On 25/08/2022 04:22, xwindows wrote:

HTTP(s) file drop, with bare POST/PUT endpoint similar to how things
like<http://0x0.st/> works; optionally with upload form.

We should start a list of "services" like that.

https://tildeverse.org/ - there's a list of services here

https://ttm.sh/ is a 0x0 server on the list with url shortening enabled
--- Synchronet 3.19a-Linux NewsLink 1.113