Issue 151 in pyftpdlib: AUTH SSL/TLS-P should also protect the data channel or be deactivated

[pyft...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-Library

New issue 151 by a.motz...@web.de: AUTH SSL/TLS-P should also protect the
data channel or be deactivated
http://code.google.com/p/pyftpdlib/issues/detail?id=151

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

[pyft...@googlecode.com]

Comment #1 on issue 151 by g.rod...@gmail.com: AUTH SSL/TLS-P should also

protect the data channel or be deactivated
http://code.google.com/p/pyftpdlib/issues/detail?id=151

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

[pyft...@googlecode.com]

Comment #2 on issue 151 by a.motz...@web.de: AUTH SSL/TLS-P should also

protect the data channel or be deactivated
http://code.google.com/p/pyftpdlib/issues/detail?id=151

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

[pyft...@googlecode.com]

Comment #3 on issue 151 by a.motz...@web.de: AUTH SSL/TLS-P should also

protect the data channel or be deactivated
http://code.google.com/p/pyftpdlib/issues/detail?id=151

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.

[pyft...@googlecode.com]

Updates:
Status: Accepted

Comment #4 on issue 151 by g.rodola: AUTH SSL/TLS-P should also protect the

data channel or be deactivated
http://code.google.com/p/pyftpdlib/issues/detail?id=151

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.