Hello Scott,
X-Posting to Midrange-L because I assume general interest.
Am 10.06.2021 um 02:27 schrieb Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>:
FTP over TLS (or SSL) works poorly
Allow me to explain a little background for fellow readers.
FTP maintains two connections: The first one where authentication is done, and setup for data connections is maintained. Data (directory listings, actual transfers) go over a *new* connection being dynamically announced by the client.
The initial protocol description provided "active FTP" as negotiation method. The connected and authenticated client instructs the FTP server to open a TCP connection to the IP address of the client on a given port for actual data transfer.
The client's IP nowadays os mostly hidden behind a firewall or (back then) a simple NAT router. So, passive FTP was invented, roles being reversed: The *client* instructs the *server* to open a data port. This works fairly well often, because access from internal networks to external ones are often allowed by default. (Keep end users and small companies in mind!)
To enable FTP to work reliably no matter if passive or active mode is used, all firewalls in the middle need to eavesdrop the connection, react on PORT commands and thus dynamically allow connections as given in the PORT command. So far, so good.
Now the initial connection is encrypted. Firewalls can't inspect the control connection anymore. Active FTP will always fail. Passive might work, if the outgoing connections aren't restricted. But I've seen servers being set up with FTP/TLS, and a firewall in front, not passing the range of ports the FTP server uses for outgoing connections by default to enable flawless function.
To overcome this obstacle, FTP/TLS was enhanced. First, a TLS connection is negotiated, so the authentication process is encrypted. Before initiating a transfer, the connection is downgraded to plain text, so firewalls can eavesdrop and enable FTP to function again.
This is a typical example of:
- It's always bad to have addresses within the protocol itself. SIP is another very bad example of such.
- Problem solving takes place in an iterative manner. Time passes, internet and the connecting entities change, and the protocol is adapted.
In the end, you'll get a complex heap of kludges with a lot of hard to track side effects and many support requests that it doesn't work and almost always shows that some firewall in the middle, or even the server is the culprit and not the FTP client.
I can clearly understand why Scott refuses to maintain such an unthankful beast and instead redirects users to a lean and "ip-less" protocol such as the ssh-based sftp or even scp.
:wq! PoC
midrange.com
