跳到主要内容

5. 安全考虑事项

本节讨论与使用票据相关的安全问题。票据必须经过认证和加密, 以防止攻击者修改或窃听。如果不谨慎处理, 下文描述的数种攻击将成为可能。

实现应当注意确保票据的处理不会增加下文所述拒绝服务的可能性。

5.1. 使会话失效​

TLS 规范要求当发生错误时使 TLS 会话失效。[CSSC] 详细讨论了这样做的安全影响。在该文的分析中, 未能使会话失效并不构成安全风险。这是因为 TLS 握手使用不可逆函数派发会话密钥, 因此关于某个会话的信息不会为攻击主密钥或攻击另一个会话提供任何优势。如果使用了会话失效方案, 实现在使用票据内容使会话失效之前, 应当先验证该票据的完整性, 以确保攻击者无法使某个选定的会话失效。

5.2. 被盗的票据​

窃听者或中间人可能获得票据并试图用它来与服务器建立会话; 然而, 由于票据已加密且攻击者不知道密钥, 被盗的票据并不能帮助攻击者恢复会话。TLS 服务器 必须 (MUST) 对票据使用强加密和完整性保护, 以防止攻击者使用暴力破解手段获取票据内容。

5.3. 伪造的票据​

恶意用户可以伪造或篡改票据, 以便恢复会话、延长其生命周期、冒充其他用户, 或者获取额外权限。如果使用如带密钥的 HMAC-SHA-256 这样的强完整性保护算法来保护票据, 这种攻击就无法实施。

5.4. 拒绝服务攻击​

推荐票据格式中定义的 key_name 字段帮助服务器高效地拒绝不是它签发的票据。然而, 对手可以存储或生成大量票据发送给 TLS 服务器进行验证。为尽量降低拒绝服务的可能性, 票据的验证应当是轻量级的 (例如使用高效的对称密钥密码算法)。

5.5. 票据保护密钥管理​

对用于保护票据的密钥的管理做完整描述超出了本文档的范围。以下给出一个推荐实践清单。

  • 密钥应当按 [RFC4086] 中的随机性建议安全地生成。

  • 密钥和密码保护算法的强度应当至少为 128 位。某些密码套件和应用可能要求强于 128 位的密码保护。

  • 除生成和验证票据之外, 这些密钥不应用于任何其他目的。

  • 密钥应当定期更换。

  • 如果票据格式或密码保护算法发生变化, 密钥应当更换。

5.6. 票据生命周期​

TLS 服务器控制票据的生命周期。服务器根据其部署环境的运营和安全需求来确定可接受的生命周期。票据生命周期可以比 [RFC4346] 中推荐的 24 小时更长。TLS 客户端可以获得关于票据生命周期的提示。由于票据的生命周期可能未指定, 客户端有自己的本地策略来决定何时丢弃票据。

5.7. 替代的票据格式与分发方案​

如果未使用本文档定义的票据格式或分发方案, 则在分析该解决方案的安全性时必须极为谨慎。特别是, 如果机密信息 (例如密钥) 被传送给客户端, 则 必须 (MUST) 使用安全通信来完成, 以防攻击者获取或修改该密钥。此外, 票据 必须 (MUST) 使用强密码技术保护其完整性和机密性, 以防止系统安全出现缺口。

5.8. 身份隐私、匿名性与不可关联性​

本文档要求对票据内容做机密性保护, 以避免其内容 (例如与用户相关的信息) 泄露。因此, 它可以防止票据中携带的潜在敏感信息被披露。

用于获取该票据的初始握手交换, 基于 TLS 的性质, 可能不提供客户端身份的机密性。另一个相关的安全威胁是, 链路上的攻击者能够观察到使用了同一票据的多次 TLS 握手, 从而断定它们属于同一对通信端点。使用本文档所述票据机制的应用设计者应当考虑到, 不必然提供不可关联性 (unlinkability) [ANON]。

虽然对这些议题的完整讨论超出了本文档的范围, 但应当指出, 可以借助在先前握手已建立安全隧道之后发生的 TLS 重协商握手来签发票据。这在某些环境中可能有助于解决一些隐私与不可关联性问题。