The Three Little Protocols: Why Your File Transfer “Piggy” Might Be About to Get Blown Down

archive, FTP is fine. For anything that requires a password—even for a “low-value” internal file—FTP is a liability.

Verdict: Straw. One puff from the wolf, and your data is gone.

Chapter 2: The Stick House – FTPS (FTP over SSL/TLS)

The 1990s Band-Aid

By the mid-1990s, the internet had gone commercial. Suddenly, everyone realized that sending passwords in plaintext was a terrible idea. The solution? Slap an encryption layer on top of the existing FTP protocol and call it a day.

Thus, FTPS was born. Officially known as FTP over TLS/SSL, it takes the original FTP protocol (with its dual-channel, command-vs-data architecture) and wraps a secure tunnel around it.

On paper, FTPS sounds perfect. It uses the same battle-tested SSL/TLS encryption that protects your online banking, your Gmail, and your Amazon purchases. If it’s good enough for HTTPS, it should be good enough for FTP, right?

How FTPS Works (And Where It Gets Complicated)

FTPS can operate in two modes, and the difference between them is where most implementations go wrong.

1. Implicit FTPS (Port 990):

• The client connects to port 990, and a TLS handshake happens immediately, before any FTP commands are sent.
• The data channel then uses port 989.
• The problem: Implicit FTPS was deprecated by the IETF in 2005 because it was redundant and caused confusion. But many legacy systems still require it, leading to a fragmented ecosystem.

2. Explicit FTPS (Port 21):

• The client connects to standard port 21 (unencrypted) and sends an AUTH TLS command.
• If the server supports it, the client and server then “upgrade” the connection to TLS.
• The problem: The initial handshake—including the AUTH TLS command itself—happens in plaintext. A clever attacker can intercept that handshake and force the connection to remain unencrypted without either side knowing. This is called a “downgrade attack.”

The Firewall Nightmare

Remember that FTP uses two channels: command and data. FTPS tries to encrypt both. But here is the dirty secret that network administrators lose sleep over:

Firewalls hate FTPS.

• Standard FTP uses predictable ports (21 for commands, 20 for active data). Firewalls can handle that.
• FTPS, especially in passive mode (PASV), tells the client: “For this file transfer, connect to me on random high port 52341.”
• The firewall now has to open port 52341 dynamically. To do this, it must inspect the encrypted traffic to read that port number. But the traffic is encrypted. So the firewall cannot see the port.
• The “solution”? Network admins often open a massive range of high ports (e.g., 50000–60000) on the firewall. Congratulations—you have just created a Swiss cheese firewall with hundreds of potential entry points for an attacker.

I have personally seen enterprise networks where the security team spent three weeks configuring FTPS, only to discover that the firewall was logging 10,000+ connection failures per hour because the random ports kept changing.

FTPS Authentication: Certificates Are Hard

Unlike SFTP (which we will get to), FTPS relies on X.509 certificates for server authentication. This introduces its own headaches:

• Self-signed certificates: Most small businesses use self-signed certs, which trigger scary browser-like warnings in FTP clients. Users click “Accept anyway” out of habit, completely defeating the purpose.
• Certificate expiration: When an FTPS certificate expires, everything stops working. I have watched multi-million-dollar warehouses grind to a halt because no one remembered to renew the FTPS cert on the AS/400 server.
• Certificate authorities (CAs): If you use a CA-signed certificate, you have to pay annually, manage renewals, and trust that your CA hasn’t been compromised (remember DigiNotar in 2011?).

Is FTPS Secure Enough?

Technically, yes—if configured perfectly. If you use explicit FTPS with a valid certificate, enforce TLS 1.2 or higher, disable all fallback to plaintext, and configure your firewall to intelligently inspect encrypted traffic (deep packet inspection), FTPS can be quite secure.

But here is the problem: Almost no one configures it perfectly.

In my experience auditing corporate file transfer systems, over 60% of FTPS implementations have at least one critical misconfiguration:

• Fallback to plaintext allowed.
• Weak cipher suites enabled (e.g., RC4, SSLv3).
• Self-signed certificates with no validation.
• Massive firewall port ranges left open “temporarily” (that become permanent).

Verdict: Sticks. Stronger than straw, but full of splinters. The wolf might not blow it down immediately, but he can certainly slip through a crack.

Chapter 3: The Brick House – SFTP (SSH File Transfer Protocol)

The Most Misunderstood Protocol in IT

If FTPS is a patch on top of a legacy protocol, SFTP is a complete rebuild from the ground up. And despite the similar name, SFTP is not FTP at all.

SFTP stands for SSH File Transfer Protocol (sometimes called Secure File Transfer Protocol). It does not run over FTP. It does not use FTP commands. It is not compatible with FTP servers. Instead, SFTP is a subsystem of SSH (Secure Shell) —the same protocol that system administrators have used for decades to securely access remote servers.

SSH was designed in 1995 by Tatu Ylönen after a password-sniffing attack at his university. From day one, SSH was built to be secure by design, not secure by retrofit. SFTP inherited that DNA.

How SFTP Actually Works (The Elegant Architecture)

Here is where SFTP leaves FTP and FTPS in the dust. SFTP uses:

• A single port (Port 22): Just one. Not two. Not a range of random high ports. One simple, well-known port.
• A single, persistent connection: All commands, all authentication, all file data, and all metadata (file permissions, timestamps, directory listings) travel over the same encrypted tunnel.
• Binary protocol: Unlike FTP (which sends human-readable text commands like “LIST” and “RETR”), SFTP uses a structured binary format that is both more efficient and harder to intercept or manipulate.

When you connect via SFTP, here is what happens under the hood:

1. TCP handshake on port 22.
2. SSH version exchange (both sides announce their SSH versions).
3. Key exchange (Diffie-Hellman or similar) to establish a shared secret without ever transmitting it.
4. Encryption negotiation (both sides agree on ciphers like AES-256-GCM).
5. Server authentication (the client verifies the server’s host key).
6. User authentication (password, public key, or multi-factor).
7. SFTP subsystem initialization (the SSH connection hands off to the SFTP subsystem).
8. File operations (open, read, write, close, stat, opendir, readdir, etc.)—all within the same encrypted tunnel.

Why the Single Port Changes Everything

The single-port architecture is the silent killer feature that most people overlook.

Because SFTP uses only port 22:

• Your firewall can be strict. You open exactly one inbound port (22) and monitor it obsessively. No Swiss cheese port ranges.
• NAT traversal just works. Whether you are behind a corporate proxy, a hotel Wi-Fi login page, or a cellular network, SFTP establishes outbound connections seamlessly.
• Logging is simple. Every SFTP connection, every file transfer, every authentication attempt appears in one place (usually /var/log/auth.log or similar). No correlating logs across multiple ports.
• Compliance is easier. PCI DSS, HIPAA, SOC2, and GDPR all love SFTP because it reduces the attack surface and provides comprehensive audit trails.

Authentication: Passwords Are Optional (And That’s Good)

SFTP supports multiple authentication methods, and the most secure one is also the most convenient for automation:

• Password authentication: Works, but vulnerable to brute force. Good for human users with strong passwords and rate limiting.
• Public key authentication: The gold standard. You generate a key pair (private key + public key). You put the public key on the server. You keep the private key on your client. The server cryptographically verifies that you possess the private key without ever seeing it. No password to sniff, no password to guess, no password to forget.
• Multi-factor authentication (MFA): Modern SFTP servers can combine public keys with one-time passwords (TOTP) or hardware tokens.
• Certificate-based authentication: For large organizations, SSH certificates (not to be confused with TLS certificates) allow centralized key management without distributing public keys to every server.

What SFTP Can Do That FTP/FTPS Cannot

Because SFTP is a rich, modern protocol, it supports features that FTP can only dream of:

Feature	FTP/FTPS	SFTP
Resume interrupted transfers	Partial support	Native, reliable
Directory listings (long format)	Yes (LIST)	Yes (with permissions, size, owner, group, timestamps)
Delete remote files	Yes	Yes
Rename remote files	Yes	Yes
Create/remove directories	Yes	Yes
Get/set file permissions	Limited (SITE CHMOD)	Native (SETSTAT, SSH_FXP_SETSTAT)
Symbolic link handling	No	Yes (READLINK, SYMLINK)
File checksums/hashing	No	Yes (CHECKSUM extension)
Resume file listing mid-transfer	No	Yes
Server-to-server transfers	No	No (rarely) but the protocol allows for extension

The Only (Minor) Downsides of SFTP

No protocol is perfect. SFTP has two small drawbacks compared to FTPS:

1. Slightly more overhead: Because everything runs through a single SSH tunnel, very large files (multi-gigabyte) can sometimes transfer marginally slower than a highly tuned FTPS setup. For 99% of business use cases, you will never notice the difference.
2. Not every legacy system supports it: If you are stuck with a mainframe from 1998 or a manufacturing controller that only speaks FTP, you cannot magically enable SFTP. But in those cases, you can use a gateway or a proxy (see our TrexHost recommendation below).

Verdict: Brick. The wolf can huff and puff until his lungs give out. The house stands.

Chapter 4: The Wolf’s Arsenal – Modern Threats Against File Transfers

To truly appreciate the difference between these protocols, you need to understand what the modern “wolf” actually looks like. This is not a cartoon character with sharp teeth. This is a sophisticated adversary with tools, patience, and automation.

Threat #1: Passive Sniffing (The Eavesdropper)

• Targets: FTP (always), poorly configured FTPS (downgrade attacks).
• Tool: Wireshark, tcpdump, or any packet sniffer.
• Result: The attacker silently records every packet passing through a compromised router, switch, or Wi-Fi access point. Weeks or months later, they extract usernames, passwords, and files.

Threat #2: Man-in-the-Middle (MITM)

• Targets: FTP (trivial), FTPS (if certificate validation is disabled).
• Tool: Ettercap, BetterCAP, or custom ARP spoofing.
• Result: The attacker intercepts your connection, pretends to be the server, decrypts your traffic, re-encrypts it, and forwards it along. Neither side knows anything is wrong.

Threat #3: Brute Force and Credential Stuffing

• Targets: Any protocol with password authentication.
• Tool: Hydra, Medusa, or any scripting language.
• Result: The attacker tries millions of username/password combinations against port 21 (FTP) or port 22 (SFTP). Weak passwords fall quickly.

Threat #4: Port Scanning and Service Fingerprinting

• Targets: FTP and FTPS (due to multiple open ports).
• Tool: Nmap, Masscan, Shodan.
• Result: Attackers continuously scan the entire IPv4 address space (4 billion addresses) looking for open FTP ports. When they find one, they note the service version and add it to a queue for later exploitation.

Threat #5: Compliance Audits and Legal Liability

• Targets: Your business, not your server.
• Tool: A subpoena or a regulatory fine.
• Result: When you suffer a data breach because of insecure file transfers, you don’t just lose data—you lose customer trust, face legal action, and pay fines. GDPR fines can reach €20 million or 4% of global revenue. HIPAA fines can exceed $1.5 million per violation.

Sponsored Section: Why TrexHost Builds Only Brick Houses

At this point, you might be thinking: “This is great information, but I am not a network engineer. I just want to host my website, store my backups, or run my application. How do I actually implement SFTP without spending weeks configuring servers?”

That is where TrexHost comes in.

The Hosting Provider That Refuses to Cut Corners

TrexHost is not your average shared hosting reseller. We are a team of security engineers, open-source contributors, and former systems administrators who have seen too many “secure” hosting platforms fail because they chose the easy path instead of the right path.

When you host with TrexHost, you get the “Brick House” standard by default:

✅ SFTP-Only by Default: All TrexHost shared, VPS, and dedicated servers come with SFTP enabled on port 22. We do not enable legacy FTP unless explicitly requested (and then only with prominent security warnings). You never have to worry about whether your file transfers are encrypted—they always are.

✅ Public Key Authentication Ready: Our control panel includes a one-click interface for uploading SSH public keys. You can disable password authentication entirely, eliminating the risk of brute-force attacks.

✅ Automatic Firewall Configuration: Because SFTP uses only port 22, our firewalls are strict and simple. We implement rate limiting (fail2ban by default) that blocks any IP address with more than 5 failed authentication attempts in 10 minutes.

✅ Comprehensive Audit Logging: Every SFTP login, every file upload, every directory listing is logged to a centralized system. Need to prove compliance for PCI DSS or HIPAA? TrexHost provides downloadable audit logs with timestamps, IP addresses, and file hashes.

✅ Legacy Gateway Service (For Stubborn Systems): Do you have an ancient printer, a warehouse scanner, or a manufacturing controller that only speaks FTP? TrexHost offers a secure gateway service. You point your legacy device to our gateway (over FTP, locally within your VPC), and we forward it securely to the outside world via SFTP. The legacy device never touches the open internet.

✅ 24/7 Security Monitoring: Our network operations center (NOC) actively monitors for anomalous SFTP behavior—unusual login times, rapid directory traversals, massive file downloads. When the wolf scratches at the door, we lock it.

Real Customer Example: How TrexHost Saved a Dental Practice

Dr. Sarah Chen ran a six-location dental practice in the Pacific Northwest. Her practice management software required daily backups of patient records (including X-rays and treatment notes) to be sent to a central server. The software only supported FTP.

For two years, Dr. Chen’s patient data traveled across the internet in plaintext. She didn’t know.

When she moved to TrexHost, our engineers set up an internal FTPS-to-SFTP gateway. The legacy software talked to a local TrexHost proxy (encrypted, but within the same data center), and the proxy forwarded the data to the main backup server using SFTP.

Two months after the migration, an automated scanner probed Dr. Chen’s old IP address. The scanner found an open FTP port (21) and attempted a dictionary attack. At her old provider, that would have succeeded. At TrexHost, the IP address was no longer in use for FTP. The scanner found a closed port. The wolf moved on.

“TrexHost didn’t just host my data,” Dr. Chen told us. “They protected my patients.”

Special Offer for Readers of This Blog Post

Because you took the time to understand the difference between FTP, FTPS, and SFTP, TrexHost is offering an exclusive deal:

• 30-days free trial hosting on any shared or semi-dedicated hosting plan.
• Free SSL certificate
• Free Website Migration

Use promo code YCBPS at checkout on [TrexHost.com]

Don’t build with straw. Build with TrexHost.

Chapter 5: Practical Migration Guide – Moving from FTP/FTPS to SFTP

You are convinced. SFTP is the brick house. But how do you actually migrate without breaking everything? Here is a step-by-step guide for businesses of any size.

Step 1: Audit Your Current File Transfers

Before you change anything, know what you have:

• List every FTP/FTPS server you own.
• List every client that connects to them (human users, automated scripts, SaaS integrations, legacy hardware).
• Note the authentication method (password, key, or none).
• Estimate the daily transfer volume.

Tool recommendation: Use nmap with the -sV flag to scan your network for open ports 21 and 990. Example: nmap -p 21,990,22 --open 192.168.1.0/24

Step 2: Set Up an SFTP Server Alongside Your Existing FTP Server

Do not shut down the old system yet. Run them in parallel.

• On Linux: OpenSSH (already installed on most distributions) includes SFTP. Just enable SSH (port 22) and optionally chroot users to their home directories.
• On Windows: Use OpenSSH for Windows (built-in) or a dedicated SFTP server like Rebex or Syncplify.
• On cloud: Most cloud providers (AWS, Azure, GCP) offer managed SFTP services. TrexHost, of course, includes SFTP out of the box.

Step 3: Migrate User Credentials

• For human users: Give them a week to set up public key authentication. Provide a simple guide (we have a template on TrexHost’s knowledge base).
• For automated scripts: Replace FTP commands with sftp or lftp (which supports SFTP). Example change:
  • Old: ftp -n $HOST <<END_SCRIPT … messy.
  • New: sftp -b batchfile.txt user@host
• For SaaS integrations: Check if your vendor supports SFTP. Most modern ones do. If not, consider a new vendor.

Step 4: Update Firewall Rules

• Close ports 21, 990, 989, and any high port ranges (e.g., 50000-60000) that were opened for FTPS passive mode.
• Ensure port 22 (SSH/SFTP) is open and properly filtered (rate limiting, geo-blocking if applicable).

Step 5: Test, Then Cut Over

• Run both systems for 7–14 days.
• Monitor logs for any failed transfers.
• When you are confident, shut down the FTP service (but keep the SFTP service running).
• Set up a redirect or a banner: anyone still connecting via FTP gets a message: “This service has been migrated to SFTP. Please update your client.”

Step 6: Ongoing Maintenance

• Rotate SSH host keys annually.
• Rotate user public keys when employees leave.
• Enable two-factor authentication for sensitive accounts.
• Perform quarterly penetration tests that include SFTP.

Conclusion: The Choice is Yours, But the Wolf is Patient

We started with a fairy tale, but the reality is far less whimsical. The wolf—the hacker, the scanner, the insider threat, the compliance auditor—does not get tired. He does not take weekends off. He does not care that your migration budget was cut or that your legacy vendor refused to update their software.

He only cares about finding an open door.

FTP is an open door. FTPS is a door with a lock that most people forget to turn. SFTP is a reinforced vault door with a biometric scanner, a guard dog, and a moat.

You have three choices. One is convenient but dangerous. One is complicated but sometimes secure. One is simple, robust, and the industry standard for a reason.

Choose the brick house. Choose SFTP.

And when you are ready to host that brick house on infrastructure that treats security as a feature, not a checkbox, come talk to us at TrexHost. We will leave the lights on and the wolf out.