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
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team
anti-censorship-team@lists.torproject.org
-
Justin Tracey -
Roger Dingledine