Protect FTP with TLS

FTPS wraps FTP in TLS. With explicit FTPS you connect on port 21, upgrade the control channel, then protect the data connections too.

I treat FTPS as two jobs: encrypt the control channel so passwords and commands stay private, then encrypt each data socket so file bytes and listings stay private too. Skipping the second job leaves half the session exposed.

If a security scan still flags cleartext after login, check whether PROT P ran. Control-only TLS is a common misconfiguration. File bytes leak on the data channel without it.

Do not send your password before the TLS handshake finishes. Do not stop at encrypting the control channel only, or file bytes still travel in cleartext on the data socket.

Here is the command sequence:

AUTH TLS
234 AUTH TLS successful
... TLS handshake ...
PBSZ 0
200 PBSZ=0
PROT P
200 Data protection set to Private
USER alice
331 Password required
PASS ****
230 User logged in

PBSZ 0 is required for the TLS mechanism. PROT P tells the server to encrypt later data connections. Every passive data socket gets its own TLS session after that.

With curl on a test host:

curl --verbose --ssl-reqd --user "$FTP_USER" \
  ftp://files.partner.test/incoming/report.csv -o report.csv

You should see AUTH TLS, then PROT P, then EPSV, then 226 in the verbose output. Validate the server certificate. -k is for throwaway labs only.

If AUTH TLS fails, stop. Do not fall back to cleartext when your policy says FTPS is required.

Implicit FTPS on port 990 starts TLS immediately. Explicit FTPS on port 21 is more common because one listener can serve upgraded and legacy clients. This lesson follows explicit mode.

Trace one protected listing with verbose output. Mark the TLS handshake, PROT P, the passive port, and the final 226.