Secure Protocols

Overview

Many protocols in everyday use were designed before encryption was a standard requirement. They transmit everything — usernames, passwords, email content, file data, commands — as plain text across the network. Anyone with access to the network path between sender and receiver can capture and read that traffic with freely available tools. The first and most impactful security decision is choosing a protocol that encrypts by default rather than hoping the network stays private.

Protocols That Send Data In the Clear

The following protocols transmit all data without encryption. Traffic sent by these protocols is readable in any packet capture:

• Telnet — remote console access; sends every keystroke, including username and password, in plain text
• FTP (File Transfer Protocol) — file transfers; authentication credentials and file contents are unencrypted
• SMTP (Simple Mail Transfer Protocol) — outbound email; message headers and body transmitted in the clear when TLS is not negotiated
• IMAP (Internet Message Access Protocol) — email retrieval; credentials and message content visible without TLS
• HTTP (HyperText Transfer Protocol) — web browsing; all form submissions, cookies, and page content sent unencrypted
• POP3 — older email retrieval protocol; unencrypted by default

The Wall of Sheep at DEF CON is a well-known public demonstration of this risk: a live display of usernames, partial passwords, IP addresses, and protocols captured from conference attendees using insecure protocols on the event network.

Secure Protocol Alternatives

For every major insecure protocol, a secure encrypted replacement exists. The secure version provides the same functionality with all traffic protected by encryption (typically TLS or SSH):

If no secure version exists: the absence of an encrypted alternative may be a deal-breaker for using that application at all in a security-conscious environment. Sending sensitive data over an unencrypted protocol is equivalent to transmitting it on a public billboard.

Verifying Encryption with Packet Captures

A packet capture is the definitive method for verifying whether traffic is actually encrypted. Tools such as Wireshark capture raw network frames and display their contents. When reviewing a capture:

• Encrypted traffic — payload appears as random binary data; you can see IP and transport headers but the application data is unreadable
• Unencrypted traffic — payload is human-readable; HTTP headers, form data, email body, or login credentials appear as plain text

If a packet capture shows readable application data, the protocol is not encrypting. This is true even if the application claims to use a secure protocol — misconfiguration can leave encryption disabled while the port number suggests it is active.

Key Terms

• In the clear / plain text — data transmitted without encryption; readable by any party on the network path
• Packet capture — recording of raw network frames; used to verify encryption and inspect traffic content
• SSH (Secure Shell) — encrypted replacement for Telnet; also used as a tunnel for SFTP
• HTTPS — HTTP over TLS; encrypts web browsing traffic
• SFTP — SSH File Transfer Protocol; encrypted file transfers over an SSH connection
• TLS (Transport Layer Security) — the cryptographic protocol underlying HTTPS, IMAPS, SMTPS, POP3S, and FTPS

Overview

Secure and insecure versions of the same service typically run on different port numbers. Port numbers give a strong hint about which protocol is in use, but a port number alone does not confirm that encryption is active. A service can listen on port 443 while TLS is misconfigured, disabled, or using a broken cipher suite. Port selection is the starting point for verifying security, not the conclusion.

Insecure and Secure Port Pairs

The most critical pair to memorize: HTTP on port 80 (unencrypted) versus HTTPS on port 443 (TLS-encrypted). This appears on the exam consistently.

Why Port Numbers Do Not Guarantee Security

Several real-world conditions cause traffic on a “secure” port to remain unencrypted or weakly encrypted:

• TLS not enabled on the server — an administrator configured the service to listen on port 443 but never enabled the TLS certificate and encryption settings
• STARTTLS downgrade — some protocols (SMTP) use STARTTLS to upgrade a plain-text connection to encrypted; an attacker can strip the STARTTLS offer, causing the client to proceed unencrypted on the standard port
• Expired or invalid certificate — the port is correct but the certificate is expired or self-signed; clients may accept the connection anyway if configured to ignore errors
• Weak cipher suites — TLS is technically active but using deprecated algorithms (RC4, SSL 3.0, TLS 1.0) that provide little real protection
• Custom applications — nothing stops a developer from running an unencrypted custom protocol on port 443

Verification steps: (1) Check the server configuration to confirm TLS is enabled and certificates are valid. (2) Run a packet capture and confirm the payload is binary/encrypted rather than human-readable. (3) Use a TLS scanner (e.g., SSL Labs) to verify the cipher suite and protocol version in use.

Key Terms

• Port 80 — default HTTP port; unencrypted web traffic
• Port 443 — default HTTPS port; TLS-encrypted web traffic
• Port 22 — SSH; encrypted remote shell and SFTP
• Port 23 — Telnet; unencrypted remote shell
• STARTTLS — mechanism to upgrade a plain-text connection to TLS on the same port; subject to downgrade attacks
• TLS downgrade attack — forcing a connection to use a weaker version of TLS or no TLS by stripping upgrade signals

Overview

Application-level encryption (HTTPS, IMAPS, SSH) protects individual protocols, but only when those specific applications are configured correctly. A complementary approach is transport-level encryption — encrypting all traffic at the network or link layer so that every packet is protected regardless of which application generated it. Two key technologies deliver this: wireless security standards (WPA3) and Virtual Private Networks (VPNs).

Wireless Network Security

Wi-Fi transmissions travel through the air as radio waves. Anyone within wireless range with a capable adapter can capture those transmissions. The security of wireless traffic therefore depends entirely on whether the access point encrypts the radio link.

Open access point (no encryption): Any device within range can capture all wireless frames. Traffic not encrypted at the application layer (HTTP, Telnet, unencrypted email) is completely readable. Even traffic on HTTPS is visible at the outer TCP/IP layer, revealing which sites a user visits (though the payload remains encrypted by TLS). Open access points are common in cafes, hotels, airports, and conference venues — exactly the environments where sensitive work is most likely to occur.

WPA3 (Wi-Fi Protected Access 3): The current generation wireless security standard encrypts all traffic between each device and the access point. Key properties:

• Each client session uses an individual encryption key — capturing another user’s traffic on the same network yields only encrypted frames
• Protects against offline dictionary attacks on the password (unlike WPA2)
• Opportunistic Wireless Encryption (OWE) mode provides encryption even on open-style networks without a password

WPA3 protects the wireless link — traffic is still decrypted at the access point and forwarded in whatever form the application uses on the wired side.

Virtual Private Networks (VPNs)

A VPN creates an encrypted tunnel between the user’s device and a VPN concentrator (a server or appliance on the destination network). All traffic sent over that tunnel is encrypted before leaving the device and decrypted only at the concentrator. The network between them — including any wireless hops, ISP infrastructure, or internet transit — sees only encrypted data.

Key VPN benefit: it protects traffic from applications that do not encrypt natively. If a legacy application only supports Telnet, wrapping that session inside a VPN tunnel means the Telnet plaintext is never exposed on the public network — it is encrypted inside the tunnel.

VPN requirements: typically requires VPN client software on the endpoint, a VPN concentrator or third-party VPN service at the destination, and authentication credentials. Site-to-site VPNs connect entire networks; remote-access VPNs connect individual users.

Choosing the Right Encryption Layer

Key Terms

• Open access point — Wi-Fi with no link-layer encryption; all wireless traffic capturable by nearby attackers
• WPA3 — current Wi-Fi security standard; per-session encryption between device and access point
• VPN (Virtual Private Network) — encrypted tunnel between device and concentrator; protects all traffic regardless of application
• VPN concentrator — the device or server that terminates VPN tunnels, decrypts traffic, and forwards it into the destination network
• Transport-level encryption — encryption applied below the application layer; protects all applications simultaneously
• Site-to-site VPN — connects two entire networks through a persistent encrypted tunnel
• Remote-access VPN — connects an individual user’s device to a remote network through an encrypted tunnel