Secure file transfer
Unfortunately, for many people "File Transfer" equals FTP. I dislike this; but if the customer insists that "HTTP" is not a suitable file transfer protocol, then the customer is king. For all its usage and updates, FTP still requires the use of two TCP connections, which makes firewalling hell. Oh well; at least in this particular instance, the firewall is not my job.
At least the customer does have some clue, and insists that no passwords should be sent over the wire in the clear. On that, we agree. Now there are several methods of securing passwords when doing something for which the name involves "ftp".
- The most well-known is "sftp", a part of the OpenSSH package. This has nothing to do with the FTP protocol; it uses a tunneled SSH connection to get at files. This means that usually, in order to get people to files on a server, you must give them shell access too (although there are ways around this). Also, not all file transfer clients support sftp (though some do). The URI scheme used for this is, usually, 'sftp://'
- Another one is FTPS, which involves opening an encrypted control connection to port 990, and then doing FTP as usual—much in the same way that HTTPS uses a different port, too. The URI scheme used for that one is, clearly, 'ftps://'
- Yet another one is using the method described in RFC4217 (October
2005) which involves an AUTH TLS command. Clearly this is superior to
the ftps option (who likes to create more holes than necessary in their
firewall?). Two problems with this RFC:
- I haven't found what the URI scheme is.
- Since there does not appear to be an RFC for the second method above, the existence of an RFC for this method appears to confuse many people, including (but not limited to) some who should know better (SEE ALSO section) that it is about ftps, which it isn't.
The fun bit is that vsftpd supports the latter two; but because everyone confused FTPS with RFC4217, the version that's packaged for rhel 5 supports the latter but not the former, while most clients support the former but not the latter.
FTP, how I loathe thee.
If FTP TLS handling is any way like the other TLS implementations I've dealt with (mostly LDAP/IMAP), there is no separate URI for it. The RFC section 4 seems to indicate so. The server should be configured to either reject commands until TLS has been established (4.2, 10.1), or to allow (certain) commands to be issued over a clear channel.
For lftp, see the ftp:ssl-force setting.
btw: the difference between FTPS and FTP/TLS is only superficial: both use the same SSL negotiation layer. The difference is in the setup sequence. For FTPS, this is SSL negotiation -> FTP session setup -> session, and for TLS, this is FTP session setup -> SSL negotiation -> session. The TLS method is preferred because, like you say, it does not require a separate port.
What would you recommend as a http file transfer program over https? I've searched for some alternatives to ftp with an easy to use web frontend. I've looked at ajaxplorer but am not sure it can be made secure enough.
This seems also for Windows GUI users an easy and secure option. The newest filezilla[1] gui filetransfer client handles sftp proberly. This application exist also as portable app for using it with non installation.
[1] http://filezilla-project.org/client_features.php
The only drawback a see for sftp is, that downloadlinks wont run inside a webbrowser.
Frank.
WEBDAV doesn't seem to work well with existing unix users and groups. It definitely is not a simple case of replacing one protocol with another. Authentication and authorization for letting people see and only see they're own files and folders seems difficult if at all possible?