Red Hat Bugzilla – Bug 134133
Proposed workaround for SSL auth in ProFTPD
Last modified: 2007-11-30 17:10:50 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10 Description of problem: ProFTPD has a design flaw that USER/PASS commands must always be executed for user to log in, even when passwords are not used to authenticate users. This makes a problem if some other mean of authentication is implemented (for example, user is autheticated using SSL/TLS). In this case, instead of returning 232 for USER command, ProFTPD will return 331, and after client sends empty PASS command, it will return code 232 (instead of expected 230). Debugging output looks like this: $ curl -E ~/usercert.pem --ftp-ssl -v ftp://username@foobar.com/ * About to connect() to foobar.com port 21 * Connected to foobar.com (192.168.1.1) port 21 < 220 FTP Server ready. > AUTH SSL < 234 AUTH SSL successful Enter PEM pass phrase: * successfully set certificate verify locations: * CAfile: /usr/share/ssl/certs/ca-bundle.crt CApath: none * SSL connection using EDH-RSA-DES-CBC3-SHA * Server certificate: [cert details deleted, not relevant] > USER username < 331 Password required for username. > PASS < 232 User username logged in. * Odd return code after PASS * Closing connection #0 curl: (11) Odd return code after PASS Included is a simple patch to work around this issue. Version-Release number of selected component (if applicable): curl-7.11.1-1 How reproducible: Always Steps to Reproduce: 1. Connect to FTP server using SSL authentication Additional info:
Created attachment 104540 [details] Workaround for brain damaged secure FTP servers
Please explain to me why curl should be patched as opposed to ProFTD? Is this change standards compatible (ie won't break any real or theoretical fully compliant ftp server out there)?
Curl should be patched in order to work with existing ProFTPD servers (even after ProFTPD is patched). There is huge installed base of ProFTPD servers out there. Also, it is not likely that ProFTPD will be patched soon, because the bug is in the design of ProFTPD's authentication module. It's not just a couple of lines of code, it needs to be revised, and possible other modules that depend on current desing of auth module. I've checked ProFTPD source and their bug tracking web page. It seems developers are aware of the problem, but there is no easy way to fix it. This workaround would enable curl to interoperate with current ProFTPD servers, until the bug in ProFTPD is fixed. The change is compatible. It should not break any real or theretically fully compliant ftp server out there becase: - Fully compliant FTP server will not require PASS command (it will return 232 as response to USER command, as defined in RFC 2228 and proposed standard described in draft-murray-auth-ftp-ssl-15.txt). Also, code 232 is not mentioned anywhere in RFC 959, so any "plain old" FTP server should never return it as response to any command. - Codes 2xx are reserved for positive completitions, so anything 2xx means server accepted the password and does not expect any further information (otherwise, it would issue 3xx if more information was needed, 4xx or 5xx in case of errors). I am not aware of any servers sending 2xx as response to PASS when they should send 3xx. Even if there are any, they wouldn't work with existing checks in curl anyhow (if I haven't missed something obvious in curl's source).
I would suggest you report problems/bugs/patches in curl to the curl project first. I have now modified the PASS response code check in curl, included in the upcoming 7.12.2 release.
Thanks. I'll keep that in mind for future.