明文协议：攻击者能看到什么

HTTP 会以未加密的纯 ASCII 文本传输所有数据。通过 HTTP 提交登录表单时，浏览器会发送一个包含用户名和密码的 POST 请求，凭据以明文形式传输。同一网络段中的任何人，或你与服务器之间的任何路由器，都可以读取完整请求，包括凭据、会话 Cookie 以及所有敏感的表单数据。

在 SSH 之前，Telnet 曾是标准的远程终端协议。Telnet 会话中输入的每个按键，都会以单个未加密的 TCP 数据包发送到服务器。攻击者捕获网络流量后，不仅能看到登录时的用户名和密码，还能看到输入的每条命令以及显示的每一行输出，从而无需任何密码学防护即可完全劫持会话。

FTP 使用 USER 命令进行身份验证，随后使用 PASS 命令；这两条命令都会以明文形式通过 TCP 21 端口发送。对 FTP 登录过程进行数据包捕获，就能看到确切的凭据。即使文件传输通道使用 FTPS 加密，初始身份验证交换仍会向任何观察者暴露密码。传统 FTP 服务器在企业环境中很常见，是容易窃取凭据的目标。

未使用 TLS 的 POP3（端口 110）和 IMAP（端口 143）会以明文发送电子邮件凭据和完整的邮件内容。当用户在咖啡店 Wi-Fi 上打开邮件客户端，而邮件服务器的配置未加密时，他们下载的每封邮件都可被网络上的任何其他设备读取。升级到 POP3S（端口 995）和 IMAPS（端口 993）后，连接从建立之初就使用 TLS。

MySQL（端口 3306）和 PostgreSQL（端口 5432）等数据库服务器默认支持未加密的连接。连接数据库时未要求启用 SSL 的应用服务器，会将查询及其结果（包括敏感个人数据）以明文形式发送到网络中。人们常常认为内网是可信的，但攻击者一旦获得任何立足点，就能立即开始嗅探数据库流量。

端口 389 上的 LDAP（轻量级目录访问协议）会以明文传输目录查询和身份验证信息。使用 Active Directory 进行身份验证的企业环境中，LDAP 绑定操作可能会将用户名和密码暴露在内网中。端口 636 上的 LDAPS 使用 TLS，端口 389 上的 STARTTLS 可以升级连接，但这些保护措施并不总是强制启用。

Redis 默认在端口 6379 上监听，且不启用身份验证和 TLS。暴露在网络中而未设置密码的 Redis 实例允许任何客户端读取所有已存储的键、执行任意命令，并可能写入配置文件。在 Redis 6.0（2020 年）增加 TLS 支持之前，所有 Redis 流量（包括缓存数据和会话令牌）都会在网络线路上完全暴露。

Memcached 是广泛使用的缓存层，没有内置的身份验证机制，并会通过 TCP 11211 端口以明文 ASCII 文本发送所有数据。开发人员通常依靠网络防火墙限制访问，但错误配置且暴露在互联网中的 Memcached 实例曾被用于放大式 DDoS 攻击和数据窃取。所有缓存内容（包括会话数据和应用程序接口响应）都对任何能够访问该端口的人可见。

传统 syslog 使用 UDP 514 端口，既没有身份验证，也没有加密。通过网络发送的系统日志可被传输路径上的任何人读取、修改或伪造。能够拦截 syslog 流量的攻击者可以实时读取安全事件，也可以注入虚假日志条目来掩盖踪迹。RFC 5425 定义了通过 TLS 传输 syslog 的方式，但许多系统仍在使用传统的明文协议。

从单个网络观测点出发，捕获明文协议流量的攻击者可以全面了解网络环境。他们能看到多个服务的用户名和密码、无需原始密码即可重放的会话令牌、正在传输的敏感数据，以及网络的内部架构。无需与目标系统交互，攻击者就能被动收集这些信息。

尽管人们对明文风险的认识已有数十年，未加密协议仍然存在，原因包括无法升级的传统系统、大型环境中的配置复杂性、高吞吐量内网链路上的性能顾虑，以及认为内网可信的假设。网络分段和零信任架构原则通过将内网流量与外部流量同等严格地审查，来打破这一假设。

以下哪种协议和端口组合默认会以明文传输身份验证凭据？

HTTP、Telnet、FTP、POP3、IMAP、原始数据库连接、LDAP、Redis、Memcached 和 syslog 默认都会在不加密的情况下传输数据。网络路径上的任何观察者都能读取凭据、会话令牌和敏感数据。所有这些协议都有使用 TLS 保护的对应版本。认为内网可信的假设很危险；零信任原则将所有流量视为可能被观察到。