3proxy icon indicating copy to clipboard operation
3proxy copied to clipboard

Outgoing traffic gets truncated

Open Fr0sT-Brutal opened this issue 4 years ago • 7 comments

My env:

  • 3proxy-0.9.2 (201124204021)
  • Windows
  • 3proxy config:
socks
proxy -p8080
  • FileZilla FTP server
  • FileZilla Client, FAR

I noticed this when uploading files to FTP server - they were shorter by 3-4% than original ones missing their tail. AFAICT file seems to be truncated with the step of 16384: shorter files are not affected, larger ones are trimmed to a step of 16384 (99138 => 49152 = 16384*3). Both HTTP and Socks5 protocols are affected.

Fr0sT-Brutal avatar Apr 16 '21 08:04 Fr0sT-Brutal

Probably, this is due to nature of FTP protocol and can not be fixed on proxy server side. The problem here is FTP client has 2 connections to server: control connection for commands transmission and data connection for file. On data transmission, FTP client

  1. sends data transmission command
  2. establishes data connection
  3. sends file to data connection
  4. closes data connection
  5. sends next command

the problem here is, this protocol is not intended to be used with a proxy. If proxy is involved, at step 4 client closes connection with proxy, but proxy may still has established connection with FTP server and may have some unsent data to FTP server. At step 5 FTP server may receive the next command before the data is actually sent. According to FTP protocol, in this case FTP server closes data connection, so some data may be lost between proxy server and FTP server. You can try to use ftppr functionality in 3proxy, it should be compatible with FAR FTP client and should not have this issue, or you can try to contact FAR plugin developers and ask them to add configurable grace period between closing data connection and sending the next command if FTP client is used with proxy server.

z3APA3A avatar Apr 16 '21 09:04 z3APA3A

Well I could have agreed but the primitive HTTP proxy app that I wrote from scratch does work flawlessly. Moreover, I doubt a software really sends a new command until it receives 226 response. Here's excerpt from FileZilla client log

15:05:53	Status:	Starting upload of D:\tmp\test.log
15:05:53	Command:	CWD /
15:05:53	Response:	250 CWD successful. "/" is current directory.
15:05:53	Command:	PWD
15:05:53	Response:	257 "/" is current directory.
15:05:55	Command:	TYPE I
15:05:55	Response:	200 Type set to I
15:05:55	Command:	EPSV
15:05:55	Response:	229 Entering Extended Passive Mode (|||443|)
15:05:55	Command:	STOR test.log
15:05:55	Status:	Connection with proxy established, performing handshake...
15:05:55	Response:	Proxy reply: HTTP/1.0 200 Connection established
15:05:55	Response:	150 Opening data channel for file upload to server of "/test.log"
15:05:56	Response:	226 Successfully transferred "/test.log"
15:05:56	Command:	MFMT 20210416085208 test.log
15:05:56	Response:	213 modify=20210416085208; /test.log
15:05:56	Status:	File transfer successful, transferred 99 138 bytes in 1 second
15:05:56	Status:	Retrieving directory listing of "/"...
15:05:56	Command:	EPSV
15:05:56	Response:	229 Entering Extended Passive Mode (|||443|)
15:05:56	Command:	MLSD
15:05:56	Status:	Connection with proxy established, performing handshake...
15:05:56	Response:	Proxy reply: HTTP/1.0 200 Connection established
15:05:56	Response:	150 Opening data channel for directory listing of "/"
15:05:56	Response:	226 Successfully transferred "/"
15:05:56	Status:	Directory listing of "/" successful

As you can see, it first waits for 226 response and only then sends the next command.

Fr0sT-Brutal avatar Apr 16 '21 12:04 Fr0sT-Brutal

Try 0.9.3, 0.9.2 had potential issues which could terminate on half-closed connection.

z3APA3A avatar Apr 16 '21 12:04 z3APA3A

Tried 3proxy-0.9.3 (201203211618), with the same results unfortunately.

Fr0sT-Brutal avatar Apr 16 '21 13:04 Fr0sT-Brutal

I just succeeded in reproducing the issue with 2 ncats

Client: type testfile.txt | ncat --proxy proxyhost:8080 --proxy-type http -vvv --send-only remotehost remoteport Server: >ncat -l remoteport -o dump.bin

Fr0sT-Brutal avatar Apr 16 '21 15:04 Fr0sT-Brutal

Can you try with current master? Compiled binaries for 32/64 windows https://3proxy.ru/temp/3proxy.zip

z3APA3A avatar Apr 22 '21 14:04 z3APA3A

Unfortunately the issue is still here. With two ncats and http proxy from a file of 1580872 bytes only 1449461 (with x32 exe) and 1441502 (with x64 exe) was received. Resulting sizes vary each time. x32: 3proxy-0.9.3 (210417181330) x64: 3proxy-0.9.3 (210417235919) Direct connection is OK (file transferred in full)

Fr0sT-Brutal avatar Apr 23 '21 07:04 Fr0sT-Brutal