[zoky]

> FTP is not secure.

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.

[shakna]

FTPS is not secure.

The AUTH command is generally sent before encryption of the connection is made.

Its also vulnerable to a huge swathe of timing and weak hash attacks.

But... When I said FTP, I meant FTP. I meant neither SFTP nor FTPS.

[zoky]

> 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.

[shakna]

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.

[zoky]

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.

[shakna]

No, the negotiation is in plaintext. You don't get to choose whether or not you use a vulnerable encryption method.

That same problem in STARTTLS is how we ended up with CVE-2011-0411.

> The TLS protocol encrypts communication and protects it against modification by other parties. This protection exists only if a) software is free of flaws, and b) clients verify the server's TLS certificate, so that there can be no "man in the middle" (servers usually don't verify client certificates).

There's no certificate verification in FTPS - it's too early - so you're screwed. [1]

FTPS is the vulnerable encryption method. It's the reason that SFTP is recommended, and FTPS is not. [2]

[0] http://www.postfix.org/CVE-2011-0411.html

[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5361

[2] https://www.spiceworks.com/tech/networking/articles/sftp-vs-...