CESA-2008-002 - rev 1

[See all my vulnerabilities at http://scary.beasts.org/security]

[Blog if you want to subscribe to new findings is at http://scarybeastsecurity.blogspot.com/]

Notes on the state of the security of FTP data connections over SSL

Programs affected: Many FTP clients and servers.
Severity: Possible hijack of FTP data connection despite SSL.

This is more of a technical note rather than a new vulnerability. It is worth noting that both FTP clients and FTP servers are to blame. Perhaps no-one cares. Certainly, not many people are using FTP over SSL. The main reason I'm writing this note up is that I haven't found a decent document elsewhere. (The original RFC, draft-murray-auth-ftp-ssl-16.txt, even has a section on the importance of client certs so the current state of affairs is surprising).

The problem is that whereas the FTP control connection has authentication in the protocol, the FTP data connections (send and receive) do not. We can naively say: we set things up to use SSL for the data connections, so cryptography makes us secure. But as usual, cryptography != security. If an attacker connects and SSL handshakes on the data connection before the legitimate user, they get to either steal the download, or supply the upload.

The likelihood of seeing this attack in the wild is probably quite low:


The best solution unfortunately requires a certain server-side and client-side behaviour. Clients should send SSL client certs, and the server should check the cert presented on data connections is the same as the one presented on the associated control connection.

Some clients allow certs to be sent, but this tends to default to off. The "ftp-ssl" command-line tool has the useful -z option. Other clients, including popular graphical ones, have no way to specify a client cert.

I've even been quite lazy with vsftpd in this area; only in the recent v2.0.6 release did I implement client cert support. Again, no-one (users or FTP clients) seem to really care, and I'm good at being lazy given half an excuse :) vsftpd 2.0.6 offers independent options to insist the client sends a cert, and to validate the cert is valid and signed by a recognized authority. If a cert is ever seen on the control connection (regardless of whether it is required or not), the same cert must appear on the data connection. Interestingly, even self-signed certs seem to have value as client-certs. The server-side digest view of the client cert seems to include some of the unique entropy associated with a cert as well as the textual name fields.

For clients that can't resonably be modified, I have a crazy idea to use the SSL session cache as a cheezy form of authentication. I don't yet have info on what percentage of clients request session re-use on their data connections, nor have I analyzed whether a server-side session cache hit represents a cryptographic-strength guarantee that the connection came from the same client.

Finally note that an active MITM could likely do much worse than mess with theft of data connections. A lot of FTP clients by default do no checking of the server cert.

There are other interesting attacks against FTP clients which issue FTP commands prior to "AUTH TLS". For example, an attacker can force a downgrade attack by forging the response to "FEAT" to not include "AUTH SSL" or "AUTH TLS", if the client drives its behaviour from this response. Such clients do exist.

CESA-2008-002 - rev 1
Chris Evans