Mon, 15 Nov 2010
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.
Some mail is welcome in /dev/null. Real mail, however, is welcome at my email address
|
|
|
|