I first encountered Electronic Data Interchange in the early 90's. The small shop I worked for at the time had no idea and just wanted to make the parts they quoted and send them when done.
The EDI request came in a box, with external modem, a paper with phone number and directions and then a smaller box with PROGRESS database software for MSDOS in side and a handful of disks containing the EDI system.
Good lord that was painful! I just plowed through it and all that pain completed a check box at Honeywell, who then sent us jobs electronically!
Yes, via FTP.
The CAD they were sending was Computer Vision and it was a full on solid model representation! At the time we were running CAD from the early enlightenment, CADKEY 3.5 for MSDOS!
Our best micro computer lacked the storage to handle the uncompressed file, which arrived on another handful of floppies that formed a multi part. Zip file, which uncompressed totaled about 40 megabytes and change! Entire systems only had 20!
The CAD system failed to translate the data too. 16bit pointers lacked the range needed. They had me fetch a patch a day or two later and it took a few hours to do.
300 kilobytes of wireframe CAD, and the parts we made were basically 5 percent of that data!
FTP can be as secure as any other protocol. Enabling encryption on the server side is generally as simple as installing a certificate and turning on an option. And most FTP clients will default to using encryption if it is available; for the clients that don’t do that, it’s just another server option to require clients to use encryption.
> And when companies say they use FTP to exchange data, they don't tend to mean SFTP. They really do mean FTP.
Because SFTP is a different and entirely unrelated protocol. The encrypted version of FTP is sometimes known as FTPS, but it’s really just a variant of FTP. So it would be inaccurate to call it SFTP, but referring to it as simply FTP doesn’t imply a lack of security.
> The AUTH command is generally sent before encryption of the connection is made.
So…? What is the danger of negotiating an encryption protocol over plaintext? No credentials or sensitive information are sent via the AUTH command, and a server that disallows unencrypted connections will simply refuse to go any further with a client that doesn’t support encryption.
> It’s also vulnerable to a huge swathe of timing and weak hash attacks.
Gonna need a source on that. And even if such attacks potentially exist, in the use case you mentioned above I’m still not seeing how encryption combined with, for example, IP whitelisting can’t effectively be as secure as anything else you could use.
I mean, if they’re really not using encryption then yeah, that’s stupid and all bets are off. But there’s nothing inherently insecure about the FTP protocol.
Negotiation over plaintext is a vulnerability, yes.
Neither side of the pipe is secured, so absolutely everyone inbetween is a MITM waiting to happen. Someone else can negotiate what encryption gets used. Such as the still supported MD5 signing-only.
Which also means your IP whitelisting does bupkus, unless you trust every single interchange of your, and your clients, telcos.
It’s only a vulnerability if you’re using vulnerable encryption methods, at which point you’ve already introduced a vulnerability. You could make the exact same argument about STARTTLS vs implicit TLS, but it’s generally understood that, as long as the only allowable protocols are themselves secure, there is no difference in security between the two.
