跳到主要内容

6. 安全考虑

6. 安全考虑 (Security Considerations)​

6.1. triple handshake 的前提条件和影响 (Triple Handshake Preconditions and Impact)​

Section 1 描述了发起 triple handshake attack 的一种方式, 并提到了会因该攻击而失效的安全机制; 更深入的讨论和图示可参见 [TRIPLE-HS]. 本节进一步讨论攻击的前提条件和影响.

要发起 triple handshake attack, 必须能够在两个不同的会话 (session) 上强制使用相同的 master secret. 为此, 必须满足两个前提条件:

  • 客户端 (client) C 必须愿意连接到恶意服务器 (server) A. 在某些上下文中, 例如 Web, 这很容易实现, 因为可以指示浏览器从不可信来源 (origin) 加载内容.

  • pre-master secret 必须在两个会话上同步. 对 RSA 和 DHE 密钥交换 (key exchanges) 而言, 这尤其容易实现; 在某些条件下, ECDHE, SRP 和 PSK 密钥交换也可以被利用来达到这一效果.

一旦 master secret 在两个会话上同步, 任何依赖 master secret 唯一性的安全属性都会被破坏. 例如, TLS exporter [RFC5705] 将不再提供绑定到当前会话的唯一密钥 (key).

TLS session resumption 也依赖 master secret 的唯一性来认证正在恢复会话的对等方 (peers). 因此, 如果恢复的是一个已同步的会话, 对等方将无法确认彼此的身份, 并且攻击者知道连接密钥 (connection keys). 显然, 攻击这一步的前提条件是客户端和服务器都支持 session resumption, 方式可以是会话标识符 (session identifier) 或会话票据 (session tickets) [RFC5077].

此外, 在同步的 abbreviated handshake 中, 整个记录 (transcript), 包括 verify_data values, 都会同步. 因此, 在 abbreviated handshake 之后, 类似 "tls-unique" [RFC5929] 的通道绑定 (channel bindings) 将不再能唯一标识该连接.

abbreviated handshakes 中 verify_data 的同步还会削弱 renegotiation indication extension [RFC5746] 的安全保证, 从而重新启用一种类似 renegotiation attack [Ray09] 的前缀注入缺陷 (prefix-injection flaw). 然而, 在 triple handshake attack 中, 客户端会看到服务器证书 (server certificate) 在不同的 full handshakes 之间发生变化. 因此, 发起该攻击阶段的一个前提条件是客户端在每次 handshake 时都接受不同的证书 (certificates), 即使它们的通用名称 (common names) 不匹配也是如此. 在 triple handshake attack 被发现之前, 这曾经是广泛存在的行为, 至少在某些 Web 浏览器中如此; 因而这些浏览器容易受到该攻击.

extended master secret extension 通过确保不同会话必然得到不同的 master secret values, 在第一阶段阻止 triple handshake attacks. 因此, 现在可以预期所有依赖 master secret 唯一性的安全属性都成立. 特别是, 如果一个 TLS 会话受到 extended master secret extension 保护, 那么恢复该会话, 使用其通道绑定, 以及允许在 renegotiation 期间改变证书都是安全的, 这意味着所有证书都由同一个对等方控制. [VERIFIED-BINDINGS] 给出了支持 extended master secret extension 的符号化密码协议分析.

6.2. Hash 函数的密码学属性 (Cryptographic Properties of the Hash Function)​

两个不同会话的 session hashes 需要彼此不同; 因此, 用于计算 session_hash 的 Hash function 需要具备抗碰撞性 (collision resistance). 因此, MD5 或 SHA1 等 hash functions NOT RECOMMENDED (不推荐).

我们注意到, 为使 renegotiation indication extension [RFC5746] 正常工作, Finished message 计算中使用的 Hash function 本来就需要具备抗碰撞性, 因为 handshake messages 上有意义的碰撞 (collision), 也就是 verify_data 上的碰撞, 可能重新启用 renegotiation attack [Ray09].

用于计算 session hash 的 hash function 取决于 TLS 协议版本 (protocol version). 当前为 TLS 1.2 定义的所有密码套件 (ciphersuites) 都使用 SHA256 或更强的 hash function, session hash 也是如此. 对于更早的协议版本, 只能假设其支持 MD5 和 SHA1, 本文档不要求遗留实现 (legacy implementations) 增加对新 hash functions 的支持. 在这些版本中, session hash 与 Finished message 一样, 使用 MD5 和 SHA1 的串接结果.

6.3. session hash 中包含的 handshake messages (Handshake Messages Included in the Session Hash)​

session_hash 旨在涵盖所有相关的会话信息 (session information), 包括密码套件协商 (ciphersuite negotiation), key exchange messages, 以及客户端和服务器身份 (identities). 计算 extended master secret 需要该 hash, 因而它必须在 Finished messages 之前可用.

本文档将 session_hash 设置为覆盖直到并包括 ClientKeyExchange 在内的所有 handshake messages. 对于现有 TLS 密码套件, 这些 messages 包含新会话的所有重要内容 -- CertificateVerify 不会改变会话内容 (session content). 同时, 这允许在 pre-master secret 之后立即计算 extended master secret, 从而使实现能够尽早从内存中清除临时 pre-master secret.

新的密码套件或 TLS extensions 可能会在 ClientKeyExchange 和 Finished 之间包含额外 messages, 并添加重要的会话上下文 (session context). 在这种情况下, 本规范的某些安全保证可能不再适用, 并且新的 man-in-the-middle attacks 可能成为可能. 例如, 如果客户端和服务器支持 session ticket extension [RFC5077], session hash 不会覆盖服务器发送的新 session ticket. 因此, man-in-the-middle 可能使客户端存储一个并非用于当前会话的 session ticket. 目前尚未知晓基于该向量的攻击, 但是如果应用程序在 session tickets 中存储超出 session hash 覆盖范围的额外信息, 则需要仔细分析.

6.4. 不支持 SSL 3.0 (No SSL 3.0 Support)​

Secure Sockets Layer (SSL) protocol version 3.0 [RFC6101] 是 TLS protocol 的前身, 它同样容易受到 triple handshake attacks 的影响, 也存在其他漏洞, 这些漏洞源于它使用了现已被认为较弱的过时密码学构造 (cryptographic constructions). SSL 3.0 已被弃用 [RFC7568].

本文档描述的对策 (countermeasure) 依赖 TLS extension, 因而无法用于 SSL 3.0. 实现本文档的客户端和服务器 SHOULD 拒绝 SSL 3.0 handshakes. 如果它们选择支持 SSL 3.0, 则产生的会话 MUST 使用 legacy master secret computation, 并且适用 Section 5.4 中的互操作性考虑 (interoperability considerations).

最后于 更新