Opened 18 years ago
Last modified 13 years ago
#818 closed Bug report
Error sending PROT P command in Explicit TLS/SSL connections
|Reported by:||pi72||Owned by:|
|Keywords:||Cc:||pi72, peter_daum, m_beli, Tim Kosse|
|Component version:||Operating system type:|
|Operating system version:|
Error sending PROT P command in Explicit TLS/SSL
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
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
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.
Change History (5)
by , 18 years ago
comment:1 by , 18 years ago
This Bug seems to be not exactly the same, but certainly
related to #1143883 and also sheds light on the problem
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).
comment:2 by , 18 years ago
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
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
Response: 230-This server supports FXP transfers
Response: 230 OK. Current restricted directory is /
Response: 211-Extensions supported:
[... bla bla bla ...]
Response: AUTH TLS
Response: 211 End.
Response: 215 UNIX Type: L8
Status: Retrieving directory listing...
Response: 257 "/" is your current location
Response: 227 Entering Passive Mode (217,67,26,75,195,139)
Command: TYPE A
Response: 200 TYPE is now ASCII
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.
comment:3 by , 18 years ago
FZ 2.2.12 can handle a rejected PROT P
comment:4 by , 18 years ago
I tried 2.2.12b and ... yes, it works now. Thanx.
FileZilla 2.2.10 log