Cloud Parts

FTPS

FTP over TLS: the same commands and the same two connections, with TLS negotiated on the control connection (explicit, port 21) or from the first byte (implicit, port 990), and optionally on every data connection.

What it is
Network protocols (file transfer protocols)
Part of
Built on FTP
Type
Open source
Made by
IETF
License
Open standard (IETF RFC)
Facts checked
8 October 2026
Website

What it is

FTPS adds TLS to FTP using the security commands of RFC 2228, as RFC 4217 (October 2005) specifies. In explicit FTPS the client connects to the normal control port, 21, in the clear and sends AUTH TLS; the server answers 234, and both sides run a TLS handshake on that connection before the client sends USER and PASS. Then PBSZ 0 and PROT P ask for every data connection to be protected too, each with its own TLS handshake; PROT C leaves data connections in the clear, which RFC 4217 suggests only for listings, data that is already encrypted or anonymous downloads. Implicit FTPS skips the negotiation: the client connects to port 990, registered with IANA as FTP control over TLS/SSL, and starts TLS immediately, as curl does for ftps:// URLs.

Because it is still FTP underneath, FTPS keeps FTP’s two connections and its active and passive modes. That interacts badly with encryption: firewalls and NAT devices that used to read the control connection to open the data port can no longer see the PASV reply. RFC 4217 offers the CCC command to switch the control connection back to plain text after login so those devices can work, at a security cost. TLS also brings what FTP lacked: the server proves its identity with a certificate, and clients can log in with certificates as well as passwords.

Why teams pick it

  • Encrypts and integrity-protects the login and, with PROT P, every file and listing
  • Certificate-based authentication of the server, and optionally of clients, using the same public key infrastructure as HTTPS
  • A small change for existing FTP clients, servers and scripts: the same commands and replies, with TLS added
  • Explicit mode lets one server on port 21 accept both plain and secured sessions, and refuse insecure ones

Watch out for

  • Firewalls and NAT can’t read the encrypted control channel to open the data port, which is the most common FTPS failure
  • Two kinds (explicit on 21, implicit on 990) and per-session choices (PROT C or P, CCC) mean client and server must agree on settings
  • A client that accepts a rejected AUTH may carry on unencrypted; scripts must insist on TLS (with curl, --ssl-reqd)
  • Every data connection needs its own TLS handshake on top of its own TCP connection

How it fits with other technologies

Explicit and implicit FTPS with curl, against a public test server · bash

# explicit: connect to port 21, upgrade with AUTH TLS, and fail if the server refuses
curl --ssl-reqd --list-only ftp://test.rebex.net/ -u demo:password

# implicit: ftps:// means TLS from the first byte, on port 990 by default
curl --list-only ftps://test.rebex.net/ -u demo:password

# both print:
# pub
# readme.txt

See it in a real stack

No architecture uses FTPS yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from1985–2005

Standard FTP sent passwords and files unencrypted. In October 1997 RFC 2228 added optional security extensions to FTP: AUTH to pick a security mechanism, PROT and PBSZ to protect data connections, and CCC to clear the command channel again. It defined a framework that different security mechanisms could plug into, rather than one mechanism; how to use it with TLS came later.

Port 990 is registered with IANA for FTP control over TLS/SSL: the approach now called implicit FTPS, with TLS from the first byte. RFC 4217 (October 2005) standardised the explicit approach instead: start on the normal port and upgrade with AUTH TLS, as had been done for SMTP and for HTTP. It noted that TLS developed from Netscape’s SSL and that client and server might actually negotiate SSL. Tools such as curl still support both, though curl’s own documentation says implicit FTPS “is usually not how FTPS is done”.

Why it’s built this way

Upgrade on the existing port
RFC 4217 follows how TLS was added to SMTP and HTTP: start in the clear on the usual port and switch with a command, so one server can offer both secured and plain sessions.
Protection chosen per data connection
TLS can protect each data connection or not (PROT P or PROT C), so a session can, for example, send public listings in the clear and files encrypted.
Allow the control channel to go back to plain text
NAT devices and firewalls expect to read the control connection to adjust their behaviour. CCC lets the session protect the login, then clear the channel, a compromise RFC 4217 describes along with its security issues.

Timeline

  1. 1985

    RFC 959 FTP sends everything unencrypted

  2. 1997

    RFC 2228 adds AUTH, PROT, PBSZ and CCC security extensions to FTP

  3. 1999

    TLS 1.0 (RFC 2246), which RFC 4217 later builds on

  4. 2005

    RFC 4217 standardises explicit FTP over TLS with AUTH TLS

Sources4 · facts checked 8 October 2026

Improve this page on GitHub