[anti-censorship-team] ftp file transfers have no protocol headers?

[Justin Tracey]

Hi,

Note that Firefox[0] and Chrome[1] are currently in the process of
removing support for FTP in the near future (2021 for Firefox, "whenever
COVID-19 passes" for Chrome).

 - Justin

[0]
https://www.fxsitecompat.dev/en-CA/docs/2020/ftp-support-will-be-removed/

[1] https://www.chromestatus.com/feature/6246151319715840

On 2020-05-25 7:53 p.m., Roger Dingledine wrote:
> Hi folks,
> 
> I was trying to help a user in #tor to get their ftp server running behind
> an onion, and rediscovering the ftp protocol's weird separation between
> the control channel and the file transfer channels, and I realized it
> could be interesting in the obfs4 / "unclassifiable protocols" context.
> 
> To recap, when you ftp a file, you connect to port 21, and tell it you
> want to download a file. In the modern era, clients and servers use
> "passive mode" by default, where the server opens a high-numbered port,
> and you connect to that port and it dumps the file on you.
> 
> I might be mistaken (please tell me if I am), but I believe there are no
> protocol headers or preamble or handshake or anything to the download. You
> just connect and the bytes start flowing.
> 
> If this is so, and if ftp were still popular, then there are a bunch of
> high-numbered-port connections which will be hard to classify by protocol
> because they are simply a file, on the network.
> 
> Of course, many files have structure of their own, including some
> "header"-like preface that e.g. says it's a zip file.
> 
> By that reasoning, a variant of obfsproxy that wrapped Tor traffic to
> look like a password-protected zip file could give it many other
> things to blend with on a large network like China's backbone.
> 
> (Compression is good but not enough, because DPI engines already know
> how to uncompress a zipped flow to look inside it. So we need some sort
> of encryption or password or the like too.)
> 
> By that reasoning also, it might be interesting to separate the two
> directional flows in an obfs connection -- i.e. so there's a "download"
> flow, and a separate "upload" flow. This approach will surely look
> weird in some contexts (two flows rather than one, and no ftp control
> connection, gotcha), but maybe in other contexts it will have many
> friends -- I'm thinking network backbones where there are many flows,
> many users are natted, and it's expensive to try to tie together state
> between permutations of flows.
> 
> If you google for 'why is ftp still used' you find a bunch of articles
> lamenting that people won't move away from it, and especially that
> large orgs won't move away from it. Maybe some of those large orgs are
> reasoning that if they secure the files contents themselves, then the
> transfer protocol doesn't matter so much. That scenario would play well
> into our goals of having a bunch of high-entropy files being passed
> around with no protocol headers.
> 
> Hm,
> --Roger
> 
> _______________________________________________
> anti-censorship-team mailing list
> anti-censorship-team at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team
>