Replacing Insecure Protocols: Telnet vs SSH, FTP vs SFTP

Many foundational internet protocols were designed in the 1970s and 1980s when security was not a primary concern. Cleartext protocols transmit all data — including usernames, passwords, and sensitive information — in plaintext over the network. Any device on the same network segment, or any system the packets traverse, can capture and read this traffic with freely available tools like Wireshark. In environments with network switches (which normally isolate traffic between ports), ARP spoofing can redirect traffic to an attacker's system, making cleartext protocols dangerous even on 'internal' networks.

Telnet (TCP port 23) provides remote command-line access to systems but transmits everything in plaintext. It has no built-in authentication beyond username/password, which are sent unencrypted. SSH (Secure Shell) (TCP port 22) replaces Telnet with an encrypted, authenticated channel. SSH uses asymmetric key exchange to establish a session key, then encrypts all subsequent communication with symmetric encryption. SSH also authenticates the server (preventing server impersonation) and supports public key authentication (passwordless but more secure than passwords) in addition to password authentication.

SSH's security relies on a robust key exchange process. When connecting, the client verifies the server's host key against a locally stored copy — this prevents server impersonation. If the host key changes unexpectedly, SSH warns the user (a common sign of a man-in-the-middle attack). After verifying the server, client authentication can use: password (encrypted in transit, susceptible to brute force), public key (client proves possession of the private key; much stronger), or keyboard-interactive (supports MFA). Organizations should enforce key-based authentication and disable password authentication on internet-facing SSH services.

FTP (File Transfer Protocol) (TCP ports 20/21) transfers files in plaintext — credentials, commands, and file data are all exposed. FTP also uses a separate data channel (passive or active mode) that complicates firewall rules. SFTP (SSH File Transfer Protocol) tunnels file transfer over SSH on port 22 — completely different from FTP, just sharing a similar name. FTPS (FTP Secure) adds TLS encryption to the original FTP protocol. SFTP is generally preferred because it uses a single port and inherits SSH's authentication and encryption. FTP should be disabled on all production systems.

HTTP (TCP port 80) transmits web content including form data, session cookies, and authentication tokens in plaintext. HTTPS (TCP port 443) wraps HTTP in TLS, providing encryption, server authentication, and data integrity. Organizations should enforce HTTPS everywhere: redirect all HTTP traffic to HTTPS (301 redirect), implement HSTS to prevent browsers from connecting via HTTP, and configure secure and HttpOnly cookie flags to prevent session tokens from being stolen via HTTP or JavaScript. Modern browsers mark HTTP sites as 'Not Secure' — HTTPS is now the baseline expectation for all web services.

SNMP (Simple Network Management Protocol) manages network devices and servers. SNMPv1 and v2c use community strings (essentially shared passwords) sent in cleartext — community strings like 'public' (read) and 'private' (write) are default values that attackers know. An attacker capturing SNMP traffic learns the community string and can read device configurations or change device settings. SNMPv3 adds authentication (HMAC-MD5 or HMAC-SHA) and encryption (AES) with per-user credentials, making it the only version appropriate for production environments. SNMPv1/v2c should be disabled.

LDAP (Lightweight Directory Access Protocol) (TCP port 389) authenticates and queries directory services (Active Directory, OpenLDAP) in cleartext by default, exposing credentials and directory data. LDAPS (LDAP over SSL/TLS, TCP port 636) encrypts the connection using a certificate. StartTLS is an alternative that upgrades an existing LDAP connection to TLS using the same port 389. Both LDAPS and StartTLS provide encryption, but LDAPS is generally simpler and more reliable. Organizations should configure all LDAP-consuming applications to use LDAPS and block plaintext LDAP on port 389 at the firewall.

Legacy email clients retrieve email using POP3 (port 110) and IMAP (port 143) in cleartext. Encrypted alternatives: POP3S (port 995, TLS) and IMAPS (port 993, TLS). Modern email platforms (Exchange Online, Google Workspace) enforce TLS for all client connections and support OAuth 2.0 token-based authentication instead of passwords. Organizations should disable basic authentication on email protocols — requiring modern authentication (OAuth 2.0 + MFA) prevents credential stuffing attacks that exploit the cleartext authentication mechanisms of legacy email protocols.

Replacing insecure protocols requires more than just enabling the secure version — the insecure version must be actively disabled. Steps: audit existing protocol usage (Nmap scans, firewall logs), migrate applications and configurations to the secure protocol, test thoroughly (business applications may break), then block the insecure protocol at the firewall and on the host. Common gotchas: legacy printers and embedded devices often only support FTP or SNMPv2; legacy industrial systems may depend on Telnet. These require network isolation or vendor replacement rather than simple protocol upgrade.

RDP (Remote Desktop Protocol) (port 3389) is widely used for remote Windows administration and is a major attack target. Insecure RDP configurations include: exposing port 3389 to the internet, using password-only authentication, and disabling NLA. Hardening RDP: enable Network Level Authentication (NLA) which authenticates before the full session opens (blocking unauthenticated connections); require TLS 1.2+ for all RDP sessions; put RDP behind a VPN or RDP gateway rather than exposing it to the internet; and enforce account lockout to prevent brute force. Many ransomware campaigns gain initial access via exposed, poorly secured RDP.

Migrating away from insecure protocols in production environments requires careful planning to avoid business disruption. A phased approach: Phase 1 — Discover: run Nmap scans and audit firewall logs to identify all uses of cleartext protocols. Phase 2 — Enable secure alternatives: configure SSH, SFTP, HTTPS alongside the existing insecure services. Phase 3 — Migrate consumers: update scripts, applications, monitoring tools, and user workflows to use the secure protocol. Phase 4 — Disable and block: disable the insecure service on each host and block the port at the firewall. Testing at each phase prevents production outages.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: cleartext protocols (Telnet, FTP, HTTP, SNMPv1/v2c, LDAP) expose credentials and data to network eavesdropping and must be replaced, secure replacements (SSH, SFTP, HTTPS, SNMPv3, LDAPS) use TLS or SSH encryption to protect the same functionality, and replacing protocols requires disabling the insecure version at the firewall and host level after auditing for legacy dependencies. Next up we explore TLS versions, cipher suites, and perfect forward secrecy.