The pros and cons of FTP over SSL
We have a requirement to receive files (25-40 mb a piece) from a variety of hosts. Currently, time is of the essence. What, if any, risks do we take by having the hosts send PGP-encrypted files to an existing FTP site versus building an ad hoc FTP server on an Aptiva (200 mhz) running Redhat Linux 7.0 and using SSL?
You face two problems when you send or receive files to an FTP server. The first is securing files while they are uploading, and second, how to keep them secure while they sit on the FTP server while you wait for the recipient to download. Your second option --creating an FTP server that supports SSL
--would allow your hosts to upload the files using an FTPS (FTP over SSL) connection. This would involve the use of an SSL layer below the FTP protocol to encrypt
the control and data channels. An alternative to FTPS is the Secure File Transfer Protocol (SFTP), which uses the SSH file transfer protocol to secure an FTP connection from client to server.
However, the problem you have with FTPS and SFTP is although the files are securely transferred to your server, once they're uploaded, anyone who accesses the server can see them, because they aren't encrypted. With this in mind, I prefer your first solution, which is to have your hosts encrypt the files using the recipients public PGP key. This option not only ensures the files are encrypted while in transit, and when at rest, but also only the intended recipient can decrypt and view the files. The best solution to your problem, however, is probably a combination of both PGP-encrypted files and a secure FTP connection. Because even if your PGP encrypted files are secure, if your hosts use plain FTP to upload files to your server the username and password used to access the server are sent in the clear. An attacker could potentially steal this information and use it to gain access to the FTP server and upload malicious files or delete existing files.
This was first published in December 2005