Better Late, Than Never
By cindi on Sep 08, 2009
I've been remiss in posting and completely missed reporting on a couple of new Q2 features for the Fishworks software stack. In Q2, we introduced three new secure data protocols: HTTPS, SFTP, and FTPS. Dave Pacheco covers HTTPS in his blog so I'll highlight SFTP and FTPS here.
Our FTP server is built from the proFTPD server software stack. In Q2, we updated the server to version 1.3.2 to take in a number of critical bug fixes and add support for FTP over SSL/TLS (FTPS). The proFTPD server implements FTP over SSL/TLS in accordance with the FTP Security Extensions defined by RFC 2228. Not all FTP clients support the FTP security extensions but a list of clients that do may be found here.
Enabling FTPS on a Fishworks appliance is very simple. From the FTP service configuration BUI page or CLI context, an administrator may optionally select to turn on FTPS for the default port or an alternate port. If FTPS is enabled for a port, the FTP server will use TLSv1 for its authentication and data channels.
The SSH File Transfer Protocol (SFTP) is a network protocol that provides file transfer over SSH. SFTP is a protocol designed by the IETF SECSH working group. SFTP does not itself provide authentication and security but rather delegates this to the underlying protocol. For example, the SFTP server used on the SS7000 is implemented as subsystem of OpenSSH software suite. The SFTP server is responsible for interpreting and implementing the SFTP command set but authentication and securing the communication channels over which the server transfers data is the responsibility of the underlying OpenSSH software. SFTP should not be confused with:
- FTP over SSL/TLS (FTPS)
- FTP over SSH
- Simple File Transfer Protocol
- Secure Copy (SCP)
Configuration of the SFTP service is very similar to SSH. The default port for SFTP is set to 218. This port was selected as it does not conflict with any other ports in a Fishworks appliance and does not interfere with SSH communication for administration (port 22). As with FTP and HTTP, shares may be exported for SFTP access by selecting read-only or read-write access from the Shares->Protocol BUI page or CLI context.
Battle of the SSL All-Stars
If you're an administrator pondering which secure protocol (HTTPS, FTPS, or SFTP) to choose, you're main consideration will be client support. Not all clients support all protocols. FTPS is limited in client adoption and the SFTP IETF specification has yet to be finalized. Secondary to client support will likely be performance. Using a simple file upload workload of a 10GB file, we can easily compare the three protocols. All three protocols use OpenSSL for encryption and decryption, so we would expect each protocol to be impacted pretty much the same for secure transfers. In the following image, we see from top to bottom, the raw network throughput for SFTP, FTPS, and HTTPS.
To be fair to FTPS and HTTPS, I used curl(1) and the native version of sftp(1) on the Solaris client (the Solaris version of curl did not support the SFTP protocol). Even so, HTTPS transfer rates are clearly lagging at almost 50% of FTPS.
Not surprising, CPU utilization increases by as much as 50% on the client and 10% on the server for a FTPS upload as compared to its non-SSL counterpart. Thanks to Bryan and the new FTP (and SFTP) analytics, we can see the difference in FTP (top pane) vs FTPS (bottom pane) data rates. FTPS can be as much as 84% slower than FTP. Ouch!
Your mileage may vary with your workload but its nice to have the tools at-hand to get a accurate assessment of each protocol and SSL implementations.