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

[giampaolo]

From alexande...@googlemail.com on January 12, 2011 21:24:52

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%2Frzaiqauth.htm

Original issue: http://code.google.com/p/pyftpdlib/issues/detail?id=151

[giampaolo]

From g.rodola on January 13, 2011 01:45:43

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)?

[giampaolo]

From alexande...@googlemail.com on January 13, 2011 02:52:20

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

[giampaolo]

From alexande...@googlemail.com on February 17, 2012 08:59:44

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.

[giampaolo]

From g.rodola on February 24, 2012 01:54:14

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.

Status: Accepted