Port 989: FTPS Data — The deprecated port that refuses to die

Port 989 carries the data channel for implicit FTPS (FTP over SSL/TLS)—an older, deprecated way of securing file transfers that never quite made it into the official standards but refuses to disappear.

What runs on port 989

Port 989 handles the data channel for implicit FTPS. While port 990 carries the control commands ("send this file," "list that directory"), port 989 carries the actual file payloads—the binary streams of documents, images, databases, everything being transferred.¹

The "implicit" part means the connection is encrypted from the first moment. No negotiation. No plaintext handshake. The client connects to port 989 and immediately starts speaking SSL/TLS. If encryption can't be established, the connection drops.²

This is different from explicit FTPS, which starts on the standard FTP ports (20/21) and negotiates encryption after the initial connection. Explicit FTPS became the official standard in RFC 4217 (2005). Implicit FTPS never got an RFC at all.³

The protocol that was never standardized

Here's the strange part: implicit FTPS was never formally defined in any RFC. It emerged in the mid-1990s as an early attempt to add SSL/TLS to FTP, but when RFC 4217 was finally published in 2005, it only standardized explicit FTPS.⁴

This means every implementation of implicit FTPS is technically operating without official specification. Different servers and clients interpret the protocol slightly differently. What works with one FTPS server might fail with another. It's the Internet equivalent of everyone speaking a dialect that was never written down.⁵

Despite this—or perhaps because of it—implicit FTPS became widely deployed in enterprise environments throughout the late 1990s and early 2000s. And once something is deployed in enterprise, it doesn't go away easily.

Why it's deprecated (but still everywhere)

Implicit FTPS is officially deprecated. Every modern security guide recommends explicit FTPS instead. The reasons are clear:

• No formal standard — Implementations vary, causing compatibility issues
• Fixed ports — Requires firewall rules for both 989 and 990
• No flexibility — Always encrypted, even when testing or debugging
• Superseded — Explicit FTPS (RFC 4217) does everything implicit FTPS does, but with standardization⁶

Yet port 989 keeps running. Financial institutions, healthcare systems, government agencies—organizations that deployed implicit FTPS twenty years ago and never migrated. The files keep flowing. The port keeps listening.

There's something almost admirable about it. A protocol that was never officially blessed, deprecated in favor of its successor, yet still trusted to move sensitive data across the Internet every day.

How implicit FTPS works

When a client connects to an implicit FTPS server:

1. Client connects to port 990 (control channel) or port 989 (data channel)
2. SSL/TLS handshake begins immediately — No plaintext negotiation
3. If encryption fails, connection drops — No fallback to unencrypted FTP
4. All commands and data flow through encrypted channels⁷

The data channel (port 989) can operate in either active or passive mode, just like regular FTP. But unlike regular FTP, every byte is wrapped in SSL/TLS before it touches the network.

Security considerations

Implicit FTPS is more stringent than explicit FTPS in one way: it never falls back to unencrypted communication. If SSL/TLS can't be established, the connection simply fails.⁸

But this rigidity is also a weakness. When troubleshooting, you can't temporarily disable encryption to isolate the problem. When testing, you can't start with plaintext and add encryption later. It's all or nothing.

The bigger concern is the lack of standardization. Different implementations might support different cipher suites, handle certificate validation differently, or negotiate TLS versions in incompatible ways. What's secure on one server might be vulnerable on another.

If you're running implicit FTPS today, you should migrate to explicit FTPS (FTPES) or, better yet, SFTP (which uses SSH on port 22 and has nothing to do with FTP despite the name).

Checking what's on port 989

To see if something is listening on port 989:

# On Linux/Mac
sudo lsof -i :989
sudo netstat -tlnp | grep :989

# On Windows
netstat -ano | findstr :989

To test if it's actually FTPS:

# Attempt SSL/TLS connection
openssl s_client -connect server.example.com:989

If you see SSL/TLS handshake output, you've found an implicit FTPS server. If the connection is refused or times out, either nothing is listening or a firewall is blocking the port.

Related ports

• Port 990 — Implicit FTPS control channel (commands)
• Port 20 — FTP data channel (unencrypted)
• Port 21 — FTP control channel (unencrypted)
• Port 22 — SSH/SFTP (completely different protocol)

The ghost in the machine

Port 989 is a ghost. It carries a protocol that was never standardized, deprecated in favor of explicit FTPS, yet still running on thousands of servers worldwide. Every day it moves files for organizations that deployed it decades ago and never found the time—or the budget—to migrate.

It's a reminder that the Internet doesn't replace old protocols cleanly. It just layers new ones on top, leaving the old ones running in the basement, carrying packets for systems that refuse to die.