Skip to main content
989

Port 989FTPS Data

TCP

Port 989 is the implicit FTPS data channel port – FTP file transfers encrypted with TLS from connection start. Paired with port 990 (FTPS control), port 989 carries the actual encrypted file data. Implicit FTPS on ports 989/990 is less common than explicit FTPS (STARTTLS on port 21) due to firewall NAT traversal issues.

Port Number

989

Protocol

TCP

Service

FTP over TLS (Data)

Range

IANA Well-Known (0–1023)

Description

FTPS data on port 989 is the encrypted equivalent of FTP's port 20 data channel. When using implicit FTPS, the control channel runs on port 990 and data transfers use port 989. TLS encryption wraps the entire data transfer – file contents, directory listings, and transfer metadata are all encrypted. Implicit FTPS (ports 989/990) starts TLS immediately without negotiation, unlike explicit FTPS which issues AUTH TLS on standard port 21. The implicit approach is simpler but has NAT/firewall issues similar to active-mode FTP – passive mode with a defined port range is usually required. Most modern deployments prefer explicit FTPS or SFTP (SSH-based, port 22) over implicit FTPS.

Security risks

  • 1Firewall traversal complexity: implicit FTPS data on 989 uses dynamic ports for passive mode (like plain FTP), making firewall rules complex and often leading to overly permissive ranges (1024-65535)
  • 2TLS downgrade risk: some FTPS clients fall back to plaintext FTP if TLS negotiation fails, silently transmitting credentials and files unencrypted
  • 3Certificate validation optional: many FTPS clients skip server certificate validation by default, making MITM attacks possible despite TLS
  • 4Implicit vs explicit confusion: mixing up port 989/990 (implicit TLS) with port 21 + STARTTLS (explicit TLS) causes connection failures that operators 'fix' by disabling TLS entirely
  • 5FTP protocol design flaws persist: even with TLS, FTP's separate control/data channels, PORT/PASV commands with embedded IPs, and stateful sessions make it fragile compared to SFTP

Firewall guidance

If FTPS is required: use explicit FTPS (AUTH TLS on port 21) rather than implicit (port 990/989) – it's more firewall-friendly and widely supported. Configure a tight passive port range (e.g., 50000-50100) and open only that range. Better: replace FTPS with SFTP (port 22, single connection, no passive port issues) or cloud transfer (S3 presigned URLs, Azure Blob SAS).

Diagnosis commands

Test implicit FTPS connection (should get TLS handshake immediately)

shell
openssl s_client -connect server:990

Test FTPS download with curl (enforces TLS)

shell
curl --ftp-ssl-reqd ftps://server:990/path -u user:pass -v

List directory via implicit FTPS

shell
lftp -e 'set ftp:ssl-force true; ls; quit' -u user,pass ftps://server:990

Audit TLS configuration on FTPS ports

shell
nmap -p 989,990 --script ssl-enum-ciphers target

Usage examples

Port 989 – FTPS Data
shell
curl --ftp-ssl-reqd ftps://host:990/file.txt
lftp -e 'set ftp:ssl-force true' -u user ftps://host
openssl s_client -connect host:990

Common services on this port

vsftpd (TLS mode)ProFTPD (mod_tls)FileZilla ServerIIS FTP (TLS)WS_FTP Server

Related ports

History

Implicit FTPS (ports 989/990) was defined in a 1996 Internet Draft that never became an RFC. It wraps FTP entirely in TLS (like HTTPS wraps HTTP). Explicit FTPS (AUTH TLS on port 21, RFC 4217) was standardized later and became the preferred approach. Despite being the older, non-standard method, implicit FTPS persists because some enterprise software only supports it. Most modern deployments choose SFTP (SSH-based) to avoid FTP's dual-channel complexity entirely.

FAQ

Implicit FTPS (990) vs Explicit FTPS (21) vs SFTP (22)?

Implicit FTPS (990/989): TLS from first byte, never standardized as RFC, declining usage. Explicit FTPS (21): starts plaintext, upgrades via AUTH TLS command (RFC 4217), most compatible. SFTP (22): completely different protocol (SSH-based), single port, no passive mode complexity, simplest firewall rules. Recommendation: use SFTP unless the remote party specifically requires FTP protocol. SFTP ≠ FTPS – they are unrelated protocols.

Why does FTPS passive mode break through firewalls?

FTPS encrypts the control channel, so the firewall can't read the PASV response containing the data port number. Without that inspection, the firewall blocks the data connection. Solutions: (1) configure a fixed passive port range on the server and open that range in the firewall, (2) use TLS session resumption (required by RFC 4217), (3) switch to SFTP which uses a single port (22) for everything.

Specification

RFC 4217 – Port 989 specification →