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
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://email@example.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
* SSL connection using EDH-RSA-DES-CBC3-SHA
* Server certificate:
[cert details deleted, not relevant]
> USER username
< 331 Password required for username.
< 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):
Steps to Reproduce:
1. Connect to FTP server using SSL authentication
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
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
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.