PASV mode came with its own security drama, and doesn't address the core issue with the (absolutely pointless) multiple-connection model of FTP.

And so, yes, firewalls and NATs "interact" with FTP --- because they all had to be hacked specifically to deal with the FTP protocol, which moots your rebuttal --- but in doing so they create additional security issues, like the NAT pinning stuff Samy Kamkar posted last year.

It shouldn't be necessary for middleboxes to hack in support for protocols by in-place editing TCP streams and dynamically changing filter/translation rules based on stuff that happens inside of connections. But, thanks to FTP, they do have to do that.

And for what? FTP is even on its own terms a terrible file transfer protocol! For instance, look at how it handles (or, commonly, doesn't handle) file listings.

FTP is an anachronism. It has no more reason to exist today than TFTP --- both were designed to make up for constraints in client software that simply no longer exist anywhere.

Have used tftp for net booting, those legacy bioses cant do anything else, as it really is trivial...

Indeed. TFTP serves its purpose pretty well. FTP doesn't.

Has there been a piece of equipment shipped in the last 10 years that legitimately couldn't get a TCP running to bootstrap itself? That's why TFTP exists: to avoid the need for TCP.

Only tftp is widely supported by embedded ROMs, for netboot or for loading a new firmware for embedded devices with broken OS images.

It's not a matter of getting TCP running. You'd need a basic http transfer client, too. Not many network bootloaders or firmware loaders support anything other than tftp.

iPXE supports http. Get iPXE into embedded bootloaders for new firmware loading, and into network device ROMs for network booting, and then people can switch. Until then, it's tftp because that's what everyone supports.

Well, remember that until recently, BIOSes ran in real mode with it's memory constraints (remember the 640k limit?).

While passive FTP solved the issue for the client, it totally breaks if the server is behind a NAT, so you are back to the firewall needing knowledge of the inner workings of the protocol.

having the two separate connections really is an anachronism which proves to be a big hassle or all parties.

And not even IPv6 will slve this one as a firewall still needs to know what port to let data through. And because the PORT command lists IP addresses, you can't even transparently run FTP over v6. It's one of te protocols where users need to have special protocol awareness beyond the length of the IP address.

One important firewall that can't deal with it: Amazon's NAT images for EC2. AFAICT, there's no way to run an ftp client behind Amazon's NAT unless you open all outbound ports, because the server is still the one that specifies which port the client should use for its PASV connection.

I think most firewalls solve this by actually rewriting the FTP packets on the fly (IIRC Cisco calls these "fixups"). That's seriously, seriously broken.

FTP is as obsolete as telnet and has no place being alive today.

SSH and SCP provide a much more secure alternative. SFTP is a hack that suffers from all the same problems.

How do you mean, SFTP is a hack that suffers from all the same problems? SFTP is a new protocol, it's not the same as FTP. It doesn't concern itself with data port nonsense, and while it doesn't offer authentication or secure transfers in itself, there is - at least to my knowledge - no SFTP solution available that doesn't perform SFTP via an underlying mechanism for secure auth/transfer.

I suspect the GP was referring to FTP over SSL, which is an ugly abomination with few redeeming features.

In this case that's FTPS (FTP over SSL), not SFTP (SSH File Transfer Protocol)

I work for a company that processes sensitive data, and almost all our interactions with clients and suppliers are over SFTP, which is more than platform-agnostic enough.

Sensitive data? Over an unsecured protocol?

Please, name me one platform in common use that doesn't have an implementation of ssh/scp.

Java, C# which covers a good 80+ percent of enterprise software. Moving data from one company to another for processing is big, big business. The type of thing not discussed on HN because it's not relevant here, but it must happen for those types of companies and FTP is really the only thing you can ask a paying client to use without asking them to rely on unsupported/abandoned/old third party libraries.

-_- Java & C# are not platforms, they're programming languages. I'm making an effort here to understand you, but I don't see how a programming language can relate to the availability of file transfer tools.

Programmatic access is essential in such an environment.

Here's a realistic scenario just to make it clearer. An email appending company lands a big client. The client wants to obtain its customers' email addresses on an ongoing basis. They'll send customer information to the email append company who will then send them back the appended files.

Manually moving files is not an option on either side. What method other than FTP do you suggest here?

OK then, while I don't have much experience with Java and C#, 15 seconds of googling showed me at least one broadly used and well supported, open source library for SSH/SCP for each of these languages. Undoubtedly, there are others that are not free but backed by a real company. This is aside from 'integrating' SCP in the way people 'integrate' FTP - by calling the command line version.

So, whether we define 'platform' as 'OS' or 'programming language', my point stands: name me one (actually used, not VMS) platform for which there is no SCP available.

The availability of SCP is irrelevant. What matters is support. I'm glad you did your research but you came to the wrong conclusion; the conclusion you should have come to is that FTP is much more tightly integrated. In C# it's part of the standard library; in Java it's an Apache library everyone has.

I think you're overvaluing what is the "best" method of file transfer. When you have to set up a file transfer process with a client, and tens or hundreds of thousands of dollars are on the line, you are going to choose the path of least resistance. That path is FTP. Clearly. If you are the much bigger company you have a better chance of doing things the "right way" but that rarely happens just because these are ultimately business decisions and business doesn't care about implementation details unless they cost money.

Most programming environments have SSH/SCP libraries. If you want to maintain a simple upload/download model, SCP is the way to do it.

It's not entirely clear to me that an FTP-style upload/download model is best here, mainly because I haven't the faintest clue what an "email appending company" does.