FTPS

The client still speaks FTP commands. The change is that the control connection, and usually the data connection, are encrypted. It is not SFTP.

RFC 4217 is explicit FTPS. The client connects to port 21 as plain FTP, then sends AUTH TLS before the password. After the TLS handshake, USER and PASS travel inside the encrypted control connection. The data connection is a second socket. The client and server negotiate whether that socket is also protected, using the FTP security extensions (PROT). A server that encrypts commands and leaves the file in the clear has done half the job. Firewalls still have to allow the negotiated data port. TLS does not remove FTP's two-connection design.

Implicit FTPS is the other mode. The socket is TLS from the first byte, conventionally on port 990. It predates RFC 4217 and was never standardized. Old servers still expect it. A client set to explicit will sit on 990 waiting for a banner that never comes in cleartext, and a client set to implicit will fail on port 21 because the server is waiting for FTP commands.

A bank's dropbox says "secure FTP, port 21." The operator turns on explicit TLS, binary type, passive mode. AUTH TLS succeeds, the certificate matches the hostname, PROT P protects the data socket, STOR writes a 200 MB NACHA file. If the firewall allows 21 and blocks the passive range, the login works and the transfer hangs at 0 bytes. That hang is the FTP data channel, not a TLS failure. Switching the same job to port 22 and a key is SFTP, a different protocol, and the AUTH TLS step does not exist there.

People label both products "secure FTP." Ask three things: port, whether the banner is FTP or an SSH handshake, and whether a second data port opens. Port 21 plus AUTH TLS is FTPS. Port 22 plus a subsystem named sftp is SFTP. Plain FTP on 21 with no AUTH is neither.