× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.