More and more hosting providers are moving to FTPS to replace FTP. But there are several aspects of modern networks that make using FTPS more challenging than FTP or the other alternatives.
Introduction
FTPS in its modern, standardized form runs on the same Internet server port as FTP (21), but allows for encryption of the control and data streams. Encryption of the control stream is most important, because under traditional FTP, the username and password were sent in cleartext and were subject to snooping. Also, with an encrypted connection, the identity of the server can be verified with a certificate, while traditional FTP was vulnerable to a man-in-the-middle attack.
There are other secure FTP alternatives. But unlike SFTP, the deprecated Implicit FTPS, or FTP over SSH, with standard FTPS the control connection can be encrypted without the data connection, which gives a lower CPU overhead for servers and makes it preferable for large hosts to employ.
The basic operation of a FTPS client is that it establishes a normal FTP connection and asks the server for a feature list. If TLS/SSL is in the feature list, then it issues either an AUTH TLS or AUTH SSL command to tell the server to switch to an encrypted control stream. After that point, all control commands are encrypted.
Passive FTP problems
This introduces a problem right away. Most FTP clients operate by default in what is known as passive mode. When a data connection is requested, the server responds with an IP address and port where the client is allowed to connect. When a server is placed behind a firewall that performs NAT, the server’s external IP address doesn’t correspond to its own internal IP address, and the client will be misdirected. The usual method to get around this is to use a NAT router that implements “connection tracking” for FTP sessions. The router will watch for FTP PORT commands and rewrite the response so that the client will be able to connect to the server successfully.
Unfortunately, when encryption is enabled on the control connection, the router cannot see through the encrypted stream in order to modify the FTP server’s response. The result is that the response passes unmodified to the client and the client attempts a connection to an address that will fail, just as if connection tracking were not employed.
The solution to this problem, which also happens to work when NAT FTP connection tracking is not available, lies in the FTP server software. The FTP server must be told to send a forced IP address for passive FTP connections as well as to restrict its port range for incoming data connections, for example to port 50000-51000. Then the router must be made to forward the data connection port range to the server.
ISP Stateful Firewall Problems
There are more problems in wait. As it turns out, many ISP’s (such as Cricket at the time of this writing) employ stateful packet inspection firewalls that attempt to actively manage FTP connections, for whatever reason. Unfortunately, these firewalls are sometimes completely ignorant that FTP can be used in SSL mode.
The situation I ran into is that while the client was properly sending data during the TLS handshake (verified with strace), the server was not receiving the data and would instead receive an EOF on the control stream, causing the connection to be closed. For Pure-FTPD, this caused the following misleading error to be logged: pure-ftpd: (?@XXXXXX.evdo.leapwireless.net) [WARNING] Sorry, cleartext sessions are not accepted on this server.\nPlease reconnect using SSL/TLS security mechanisms.
After extended debugging, including replacing the server and client software, I found that the client would make a successful connection if I forwarded port 2121 to the server’s port 21 and had the client connect to port 2121 instead. Therefore, something was interfering with the client’s FTP sessions outgoing to port 21, which had the side effect of completely disabling TLS-enabled sessions.