Skip to main content

11. Security Considerations (安全考虑)

IMAP4rev1 协议事务 (包括电子邮件数据) 通过网络以明文形式发送, 除非协商了防窥探保护. 这可以通过使用 STARTTLS, 在 AUTHENTICATE 命令中协商隐私保护, 或其他保护机制来完成.

11.1. STARTTLS Security Considerations (STARTTLS 安全考虑)​

本文档中 STARTTLS 命令和 LOGINDISABLED 能力的规范取代了 [IMAP-TLS] 中的规范. [IMAP-TLS] 对于 PLAIN [SASL] 认证器仍然是规范性的.

IMAP 客户端和服务器实现必须 (MUST) 实现 TLS_RSA_WITH_RC4_128_MD5 [TLS] 密码套件, 并且应该 (SHOULD) 实现 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] 密码套件. 这很重要, 因为它确保任何两个兼容的实现都可以配置为互操作. 所有其他密码套件都是可选的 (OPTIONAL). 请注意, 这是对 [IMAP-TLS] 第 2.1 节的更改.

在 [TLS] 协商期间, 客户端必须 (MUST) 将其对服务器主机名的理解与服务器证书消息中呈现的服务器身份进行核对, 以防止中间人攻击. 如果匹配失败, 客户端应该 (SHOULD) 要求明确的用户确认, 或终止连接并指示服务器的身份可疑. 根据以下规则执行匹配:

  • 客户端必须 (MUST) 使用其用于打开连接的服务器主机名作为要与服务器证书中表示的服务器名称进行比较的值. 客户端不得 (MUST NOT) 使用从不安全远程源 (例如, 不安全的 DNS 查找) 派生的任何形式的服务器主机名. 不执行 CNAME 规范化.

  • 如果证书中存在 dNSName 类型的 subjectAltName 扩展, 则应该 (SHOULD) 将其用作服务器身份的来源.

  • 匹配不区分大小写.

  • "*" 通配符字符可以 (MAY) 用作证书中最左侧的名称组件. 例如, *.example.com 将匹配 a.example.com, foo.example.com 等, 但不会匹配 example.com.

  • 如果证书包含多个名称 (例如, 多个 dNSName 字段), 则与任何一个字段的匹配都被认为是可接受的.

客户端和服务器都必须 (MUST) 检查 STARTTLS 命令和后续 [TLS] 协商的结果, 以查看是否实现了可接受的认证或隐私.

11.2. Other Security Considerations (其他安全考虑)​

由于无效凭据而失败的 AUTHENTICATE 命令的服务器错误消息不应该 (SHOULD NOT) 详细说明凭据无效的原因.

使用 LOGIN 命令会以明文形式发送密码. 这可以通过使用不使用明文密码的 [SASL] 机制的 AUTHENTICATE 命令, 或首先通过 STARTTLS 或其他保护机制协商加密来避免.

服务器实现必须 (MUST) 实现一个配置, 在认证时要求:

(1) 已协商 STARTTLS 命令.

或

(2) 已提供其他保护会话免受密码窥探的机制.

或

(3) 采取以下措施:

  • (a) 宣告 LOGINDISABLED 能力, 并且在 CAPABILITY 列表中不宣告使用明文密码的 [SASL] 机制 (例如 PLAIN).

  • 并且 (b) 即使密码正确, LOGIN 命令也会返回错误.

  • 并且 (c) 对于所有使用明文密码的 [SASL] 机制, 即使密码正确, AUTHENTICATE 命令也会返回错误.

失败的 LOGIN 命令的服务器错误消息不应该 (SHOULD NOT) 指定用户名 (而不是密码) 无效.

服务器应该 (SHOULD) 具有限制或延迟失败的 AUTHENTICATE/LOGIN 尝试的机制.

讨论 AUTHENTICATE 和 LOGIN 命令的章节中讨论了其他安全考虑.

Last updated on