Hi,
I am thinking about adding ftp protocol support to stunnel4. first, some restrictions to simplify the implimentation: 1) only support for stunnel running in server mode, users can use ftp clients which support ssl connection (ie. FlashFXP) to connect to the real ftp server through stunnel daemon; 2) only support standalone service mode of stunnel. (inted support may be added later, I've just read the source code related to standalone service, and have not got any clue about how to support inetd.) 3) only support FTP implicit SSL and PASSIVE mode;
the code may look like this: (the real ftp server is at 192.168.10.254, listening on port 21.)
1) start a stunnel daemon nonmally with accept = 990, remote = 192.168.10.254:21, protocol = ftp; 2) when a connection come in, parse the ftp server response, search for "227 Entering Passive Mode (192,168,10,254,133,22)", then got the data connection IP: 192.168.10.254 PORT: 34070; 3) plus 1 to the data connction port 34070, then we got 34071 which will be used as stunnel accept port; 4) create a LOCAL_OPTIONS structure instance opt (prototypes.h) dynamically, set opt->accept=1, opt->local_addr same to the parent stunnel, change its port to 34071, opt->remote_addr = real data connection (IP: 192.168.10.254 PORT: 34070); opt->fd = socket(), bind(); 5) set local_option->next = opt; 6) s_poll_add (&fds, opt->fd, 1, 0); (stunnel.c) (the local variable fds needs to be changed to a global variable, by the way, I think it is also required if stunnel want real SIGHUP configuration-on-the-fly support) 7) changed server response to "227 Entering Passive Mode (STUNNEL_LOCAL_HOST,133,23)", then send back to client. 8) the client will then connect to STUNNEL_LOCAL_HOST port = 34071, negotiate SSL session and send/receive data; 9) after ftp session finished (How to know a ftp session is finished?), free the dynamic LOCAL_OPTIONS opt, remove opt->fd from fds, close the data sessoin.
There are only two source file (stunnel.c, protocol.c) need to be modified to implement these functions.
Any suggestions will be appreciated. Thank you.
Zhuang Yuyao 2005/7/28
Any suggestions will be appreciated.
Not that they're nice suggesions:
1) don't use Stunnel for something as already broken as ftp. If you must use ftp w/ ssl support, get an ssl enabled ftp server, such as proftpd.
2) ssl-protected ftp is not going to work through firewalls nicely because the firewall can't inspect the packets to re-write the IP addresses, or allow the ephemeral ports, so you're stuck hoping they have a permissive outbound firewall, you've got dedicated ports open on your firewall that allow anything from anyone without restriction and your ftp server is hard coded to use only ephemeral ports in that range, and that the client uses passive ftp only because active just plain won't work.
3) ftp icky. icky icky icky icky.
Brian Hatch wrote:
Not that they're nice suggesions:
- don't use Stunnel for something as already broken as
ftp is one of the most widely used protocols, may be it is broken, but people are still using it.
ftp. If you must use ftp w/ ssl support, get an ssl enabled ftp server, such as proftpd.
I know there are many ssl enabled ftp servers, but if I've deployed stunnel in my networks, established a PKI environment around it, setted access control to my http, pop3, smtp, imtp servers in stunnel.conf, I'd be fairely happy if I can add ssl ftp support by just add a few lines to my stunnel.conf, avoid the annoying process of downloading/compiling/installing a ssl enabled ftp server, migrating my previous ftp server settings to the new one, read its configuration manual, testing and hope everything is OK, and after 1 month, some new requirements force me to read its manual again because I total forget how to use it.
I've started to write codes to add ftp support to stunnel based on version 4.11 today, now my FlashFXP can connect to ftp server through stunnel, list files (the LIST command works), but still can not download a file (RECV failed. the log on the client side shows the ssl negotiation is ok, but stunnel.log complains for "SSL_write returned WANT_WRITE: retrying" "SSL_read returned WANT_READ: retrying").
Now I have more confident in the approach I described in my last mail.
- ssl-protected ftp is not going to work through firewalls nicely because the firewall can't inspect the packets to re-write the IP addresses, or allow the ephemeral ports, so you're stuck hoping they have a permissive outbound firewall, you've got dedicated ports open on your firewall that allow anything from anyone without restriction and your ftp server is hard coded to use only ephemeral ports in that range, and that the client uses passive ftp only because active just plain won't work.
Please consider such a situation, a company which has already setted up their firewall rules to allow access to the ftp server, they're using it everyday (from both WAN and LAN), but without encryption, the password is unsafe. adding a stunnel in front of the ftp server is the simplest solution.
Even if the firewall is an unavoidable problem, at least we solved the security problems in LAN ftp access, which, in my opinion, is more critical than the possible attacks from the outside Internet.
3) ftp icky. icky icky icky icky.
Yes, I agree :-)
To me, adding this functionality to stunnel because I like this software and if FTP protocol had been supported, plus some other improvments (ie. access control, configuration-on-the-fly, etc.), will make stunnel an ideal choice for a real SSLVPN.
Zhuang Yuyao
ZHUANG YUYAO zhuangyy@netease.com wrote on 28-07-2005 06:10:04:
Hi,
I am thinking about adding ftp protocol support to stunnel4. first, some restrictions to simplify the implimentation:
...
- only support FTP implicit SSL and PASSIVE mode;
I would strongly discourage you from adopting FTP with implicit SSL. As I write, ftp://ftp.isi.edu/internet-drafts/draft-murray-auth-ftp-ssl-16.txt is three slots from the top of the RFC editor's queue, meaning it is likely to become in RFC in the next few weeks. This specifies that implicit SSL is deprecated, and this was done because the IETF disapproves of implicit SSL in principle (I believe HTTPS slipped through because it was a de-facto standard by the time it was written up as an RFC).
I'm not sure how you could implement explicit SSL using stunnel without putting some very FTP specific code right into stunnel. There are a few implementations of FTPS to FTP proxies out there already however: http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html#proxy