Protect FTP with TLS

FTPS is FTP secured with TLS. In explicit FTPS, the client connects to the normal FTP service and sends AUTH TLS. After a successful reply, the TLS handshake protects the control channel.

The client uses PBSZ 0 for TLS and PROT P to require private, encrypted data connections. Protecting only the control channel would still expose file contents and listings.

The client must validate the server certificate. Encryption without identity validation can connect securely to the wrong server.

The control upgrade is a state transition:

C: AUTH TLS
S: 234 AUTH TLS successful
...TLS handshake and certificate validation...
C: PBSZ 0
S: 200 PBSZ=0
C: PROT P
S: 200 Data protection set to Private

Send credentials only after the handshake. PBSZ 0 is required for the TLS protection mechanism. PROT P requests confidentiality and integrity for later data connections.

Every passive data connection gets its own TLS protection. That increases handshake and firewall complexity. Reusing the protected control connection does not encrypt a separate data socket automatically.

Do not silently fall back when AUTH TLS or PROT P fails. A client configured to require FTPS should stop instead of completing the same transfer in cleartext.

Trace one protected listing with verbose output. Mark the control handshake, PROT P, passive endpoint, data-channel handshake, and final 226.