Error sending PROT P command in Explicit TLS/SSL connections

[pi72]

Error sending PROT P command in Explicit TLS/SSL
connections

This bug *may* be the same as 906633, 965367 and 1143883.

Symptoms: FileZilla connects using Explicit TLS or SSL
connection but fails to get a directory listing.

Version: FileZilla 2.2.10 trying to connect to a
RaidenFTP server.

Description: With the help of the guy running the
server, we traced down the problem to be with the order
of login and sending the PROT P command. In other
clients like CuteFTP Pro, the client first logs in and
then issues the command PROT P, which is accepted. With
FileZilla, it first issues the command PROT P, which is
rejected, and then logs in. FileZilla then fails to
retrieve a file listing. Although then you can manually
issue PROT P or PROT C commands and they are accepted,
you can't still get a file list.

Configurations tried: Using port 21, this exact problem
happens with both active and passive mode, and with
both "FTP over SSL (explicit encryption)" and "FTP over
TLS (explicit encryption)". Also tried disabling
compression, which seems to have nothing to do with
this problem.

Comments: Apparently FileZilla doesn't know how to
handle the transfers after PROT P being rejected. This
might need to be handled. Although I'm not aware of how
the Explicit TLS/SSL connection standard describes the
adequate process of connection, it might be worth it to
place somewhere an option to send PROT P before or
after the login for these kind of connections. Another
option would be resending PROT P *after* the login in
the case it was rejected when sent before it.

Attachment: A log with Trace and Show Listings enabled.
Host details have been removed for privacy. The two
last commands were sent manually to show their results
after the login.

[pi72]

FileZilla 2.2.10 log

[peter_daum]

This Bug seems to be not exactly the same, but certainly
related to #1143883 and also sheds light on the problem
with pure-ftp:
Pure-Ftp currently currently can encrypt only the control
channel, the data connection is always un-encrypted, so
"PROT P" should always fail. If FileZilla can't handle cleartext
data connections when in TLS mode, this can't work.
I don't think that a configuration option, when to issue a
"PROT P" command would make much sense - before
authentification there can't be a data connection,
sending the command after login should always work.

What would make a lot of sense IMHO (and probably fix my
communication problem with pure-ftp :-) is a configuration
option whether in TLS mode only the control channel should
be encrypted (which would be sufficient to protect the most
sensitive information: the password) or to also encrypt the
data connections (more privacy, less performance).

[m_beli]

Yes, I have the same problems.
FileZilla seems to ignore RFCs about encrypted connections
by ignoring the response to "PROT P". Below I copy the log
of filezilla connecting to PureFTPd. Filezilla negotiates
explicit TLS successfully, then issues "PROT P" command but
gets negative response, ignores it and later tries to get
directory listing using TLS and fails ofcourse.

---

Status: Connecting to a.b.c ...
Status: Connected with a.b.c, negotiating SSL connection...
Response: 220-Welcome to Pure-FTPd.
[... bla bla bla ...]
Command: AUTH TLS
Response: 234 AUTH TLS OK.
Status: SSL connection established. Waiting for welcome
message...
Command: PBSZ 0
Response: 200 PBSZ=0

Command: PROT P
Response: 534 Fallback to [C]

Command: USER beli
Response: 331 User joe OK. Password required
Command: PASS *
Response: 230-User joe has group access to: admin adm

users

Response: 230-This server supports FXP transfers
Response: 230 OK. Current restricted directory is /
Command: FEAT
Response: 211-Extensions supported:
[... bla bla bla ...]
Response: AUTH TLS
Response: PBSZ
Response: PROT
Response: 211 End.
Command: SYST
Response: 215 UNIX Type: L8
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is your current location
Command: PASV
Response: 227 Entering Passive Mode (217,67,26,75,195,139)
Command: TYPE A
Response: 200 TYPE is now ASCII
Command: LIST
Response: 150 Accepted data connection
Error: Can't establish SSL connection
Error: Could not retrieve directory listing
Response: 226-Options: -a -l
Response: 226 51 matches total

---

This is really annoying, 'cause i can't afford the CPU usage
when encrypting large ammounts of data transfer and
encrypting only control connection is quite suitable sollution.
The same setup which fails with FileZilla works well with
SmartFTP (win) or LFTP (linux) for example.

[Tim Kosse]

FZ 2.2.12 can handle a rejected PROT P

[m_beli]

I tried 2.2.12b and ... yes, it works now. Thanx.