How secure is FTP over TLS? Confused about certificate process

[markmarz]

Hi,

I don't understand how generating a certificate on the server side and acknowledging it on first connect with my FileZilla client is secure. Probably due to my general ignorance.

It seems to me that anyone could set up a FileZilla client and, if they know the server URL, could attempt to connect using FTP over TLS. They're prompted to accept or reject the certificate. So they accept it. Now (or in the client configuration) they have to sign in with a userid and password. So it all boils down to user credentials, right?

In my case I don't want to encrypt the data, just the commands, because the data doesn't need to be secure. So I suppose the credentials are encrypted, and that's a good thing, but still if I have the correct userid and password, I'm in.

Am I missing something?

Thanks,
Mark M

[botg]

While you may not need to encrypt the data, you still want to authenticate it to ensure that the data received is the data sent.

E.g. if I'm on vacation and sent my mother a postcard saying "I'm fine, weather is good, food is plenty", I don't mind others from reading that, but I don't want whoever is touching the postcard from using eraser and scribbling something nasty on it. above my signature.



If the client verifies the fingerprint of the certificate against the reference fingerprint obtained offline from the server administrator, the client has the guarantee that the connection is authentic. He can then log into the server using his username and password. Done in this order, both the client and the server know that the connection is confidential and authentic, both ways.

[boco]

Yes, you are missing the true reason of FTP over TLS. It is all about end-to-end encryption, in order to spoil man-in-the-middle attacks. FTP over TLS is not an authentication mechanism to replace passwords, nor is it any type of access control! You still have to keep your login data secret.

[markmarz]

Thanks for your reply. Please continue being patient, as some not smart questions follow.

Please clarify how I, as the client, can verify the fingerprint of the certificate.

It's still not clear to me how the server knows I'm who I say I am, except for the fact that I'm logging in with the expected userid and password. The certificate helps me, the client, know the server is my server (once I know how to verify fingerprint). But it doesn't help the server know who the client is, right?

I'm comparing this to something like OpenVPN, where there is a certificate held at both sides.

My goal is to be able to sign on securely (so that no one can intercept my credentials in the clear) and then download unencrypted files from the server. I want to be sure only I can do that. I know I can restrict client IPs, but that's another thing. Trying to understand how credentials that only exist on server side aid in verifying the identity of the client.

Thanks!
Mark

[markmarz]

Yes, you are missing the true reason of FTP over TLS. It is all about end-to-end encryption, in order to spoil man-in-the-middle attacks. FTP over TLS is not an authentication mechanism to replace passwords, nor is it any type of access control! You still have to keep your login data secret.

FTP over TLS is not an authentication mechanism? In my case, where I don't care about encrypting the data, are you saying I'm just as well off not using TLS? I think the only advantage to TLS in my scenario is it encrypts the userid and password, which as I said is a good thing. But is that it?

[botg]

The server knows who you are you because of the password.

Same thing with OpenVPN, there your private key (and associated key) are in essence your password through which the server identifies you.

[boco]

FTP over TLS ensures that data sent forth and back between the endpoints (your client vs. the server endpoint) arrives unaltered and cannot be read by any bad guys along the line. When logging in, a session key is created that acts as temporary authentication. Any session keys are lost when disconnecting.
A TLS certificate identifies the server, but won't restrict what clients can connect to it. There is no permanent client identification.

There is TLS-C (PROT C, encrypting only the command channel) and TLS-P (PROT P, encrypting both command and data channels). FileZilla only supports the latter (it always sends PROT P and expects an encrypted data stream at all times).


Analogy: FTP over TLS is for the FTP protocol what HTTPS is for HTTP. HTTPS sites also can not and do not restrict what clients connect to them.

[markmarz]

Thank you boco! Your explanation is crystal clear, I really appreciate it. The HTTP/HTTPS analogy really drove it home. Also thank you botg, nice tag team! Hah-hah!

Also thanks for the extra information on PROT C; I was planning on using that since I'll be transferring large video files that I didn't want to encrypt to avoid overhead. Oh, well!

Thanks!
Mark

[botg]

With modern CPU the overhead if negligible.