AUTH SSL/TLS-P should also protect the data channel or be deactivated

[GoogleCodeExporter]

What steps will reproduce the problem?
1. I tested the contributed TLSHandler with the netkit-ftp-ssl client. A 'ls' 
command will abort with a TLS error.

What is the expected output? What do you see instead?
netkit-ftp-ssl first uses the deprecated 'AUTH SSL' and only when that fails 
uses 'AUTH TLS', 'PBSZ 0', 'PROT P'. 'AUTH SSL' and 'AUTH TLS-P' are deprecated 
(I didn't found any references to it in a RFC) but were used to activate 
encryption on control and data channel (without the need for a PROT command). 
So netkit-ftp-ssl expects encrypted data on the data channel and gets clear 
text, so it aborts.

What version of pyftpdlib are you using? On what operating system? Which
Python version?
trunk r807, Linux, Python 2.5

Please provide any additional information below.

I modified ftp_AUTH in TLS_FTPHandler:
        def ftp_AUTH(self, line):
            """Set up secure control channel."""
            arg = line.upper()
            if isinstance(self.socket, SSL.Connection):
                self.respond("503 Already using TLS.")
            elif arg in ('SSL', 'TLS-P'):
                self.respond('234 AUTH %s successful.' %arg)
                self.secure_connection(self.ssl_context)
                self._pbsz = True
                self._prot = True
            elif arg in ('TLS', 'TLS-C'):
                # From RFC-4217: "As the SSL/TLS protocols self-negotiate
                # their levels, there is no need to distinguish between SSL
                # and TLS in the application layer".
                self.respond('234 AUTH %s successful.' %arg)
                self.secure_connection(self.ssl_context)
            else:
                self.respond("502 Unrecognized encryption type (use TLS or SSL).")

Alternatively 'AUTH SSL/TLS-P' could be deactivated, because they're deprecated 
anyway. (netkit-ftp-ssl would fall back on 'AUTH TLS' and then correctly issue 
PBSZ and PROT commands.)

References for 'AUTH SSL/TLS-P':
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=%2Frzaiq%2
Frzaiqauth.htm

Original issue reported on code.google.com by alexande...@googlemail.com on 12 Jan 2011 at 8:24

[GoogleCodeExporter]

I usually tend not to will to comply with such broken FTP client 
implementations.
Moreover, netkit-ftp client latest version goes back to year 2000 so I'm not 
sure how many other clients might be uncompliant in the same manner.
Do you know if proftpd support this syntax (TLS-C, TLS-P)?

Original comment by g.rodola on 13 Jan 2011 at 9:45

[GoogleCodeExporter]

Proftpd supports AUTH SSL, TLS-C and TLS-P as described.

Original comment by alexande...@googlemail.com on 13 Jan 2011 at 10:52

[GoogleCodeExporter]

Why do you think that netkit-ftp-ssl is broken?

Because it tries to use 'AUTH SSL' first? Then why does pyftpdlib supports 
'AUTH SSL' at all, when using that is a sign of brokenness (removing the 
support would be okay, as I stated earlier)?

Or because after a successful 'AUTH SSL' it expects the data channel to be 
encrypted as well? That's what other clients and servers that support 'AUTH 
SSL' do. And there is no specification that I know of saying otherwise.

Original comment by alexande...@googlemail.com on 17 Feb 2012 at 4:59

[GoogleCodeExporter]

Sorry for the delay.
Looking back on this I think we should treat "AUTH SSL" similarly to proftpd's.
I'll make sure to fix this for the next pyftpdlib release.

Original comment by g.rodola on 24 Feb 2012 at 9:54

• Changed state: Accepted