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