跳到主要内容

5. 扩展协商 (Extension Negotiation)

5. 扩展协商 (Extension Negotiation)​

5.1. 扩展定义 (Extension Definition)​

本文档定义了一个新的 TLS 扩展 (extension), extended_master_secret (扩展类型为 0x0017), 用于通知客户端和服务器使用扩展主密钥 (extended master secret) 计算. 该扩展的 extension_data 字段为空. 因此, 该扩展的完整编码为 00 17 00 00 (十六进制).

尽管本文档仅提及 TLS, 此处提出的扩展也可以用于数据报 TLS (Datagram TLS, DTLS) [RFC6347].

如果客户端和服务器就此扩展达成一致, 并且执行完整握手 (full handshake), 则客户端和服务器都 MUST (必须) 使用 第 4 节 中定义的扩展主密钥派生算法. 所有其他密码学计算保持不变.

5.2. 客户端和服务器行为: 完整握手 (Client and Server Behavior: Full Handshake)​

下文使用短语 "中止握手" 作为简写, 表示通过发送致命的 handshake_failure 警报来终止握手.

在所有握手中, 实现本文档的客户端 MUST (必须) 在其 ClientHello 中发送 extended_master_secret 扩展.

如果实现本文档的服务器收到 extended_master_secret 扩展, 则 MUST (必须) 在其 ServerHello 消息中包含该扩展.

如果 ClientHello 和 ServerHello 都包含该扩展, 则新会话使用扩展主密钥计算.

如果服务器收到不带该扩展的 ClientHello, 并且不希望与旧版客户端互操作, 则 SHOULD (应当) 中止握手. 如果它选择继续握手, 则 MUST NOT (禁止) 在 ServerHello 中包含该扩展.

如果客户端收到不带该扩展的 ServerHello, 并且不希望与旧版服务器互操作, 则 SHOULD (应当) 中止握手.

如果客户端和服务器选择在没有该扩展的情况下继续完整握手, 则它们 MUST (必须) 对新会话使用标准主密钥派生. 在这种情况下, 新会话不受本文档所述机制保护. 因此, 实现者应遵循 第 5.4 节 中的指南, 以避免危险的使用场景. 特别是, 不应将从新会话派生的主密钥用于应用层认证.

5.3. 客户端和服务器行为: 缩略握手 (Client and Server Behavior: Abbreviated Handshake)​

客户端 SHOULD NOT (不应) 提供缩略握手 (abbreviated handshake) 来恢复未使用扩展主密钥的会话. 相反, 它 SHOULD (应当) 提供完整握手.

如果客户端为了支持旧版不安全恢复而选择即使对这类会话也提供缩略握手, 则当前连接不受本文档中的机制保护. 因此, 客户端应遵循 第 5.4 节 中的指南, 以避免危险的使用场景. 特别是, 即使客户端和服务器支持重协商指示扩展 (renegotiation indication extension) [RFC5746], 此连接上的重协商也不再安全.

提供缩略握手时, 客户端 MUST (必须) 在其 ClientHello 中发送 extended_master_secret 扩展.

如果服务器收到一个用于缩略握手的 ClientHello, 请求恢复一个已知的先前会话, 则其行为如下:

  • 如果原始会话未使用 extended_master_secret 扩展, 但新的 ClientHello 包含该扩展, 则服务器 MUST NOT (禁止) 执行缩略握手. 相反, 它 SHOULD (应当) 继续执行完整握手 (如 第 5.2 节 所述), 以协商新会话.

  • 如果原始会话使用了 extended_master_secret 扩展, 但新的 ClientHello 不包含该扩展, 则服务器 MUST (必须) 中止缩略握手.

  • 如果原始会话和新的 ClientHello 都未使用该扩展, 则服务器 SHOULD (应当) 中止握手. 如果它为了支持旧版不安全恢复而继续执行缩略握手, 则该连接不再受本文档中的机制保护, 并且服务器应遵循 第 5.4 节 中的指南.

  • 如果新的 ClientHello 包含该扩展, 且服务器选择继续握手, 则服务器 MUST (必须) 在其 ServerHello 消息中包含 extended_master_secret 扩展.

如果客户端收到接受缩略握手的 ServerHello, 则其行为如下:

  • 如果原始会话未使用 extended_master_secret 扩展, 但新的 ServerHello 包含该扩展, 则客户端 MUST (必须) 中止握手.

  • 如果原始会话使用了该扩展, 但新的 ServerHello 不包含该扩展, 则客户端 MUST (必须) 中止握手.

如果客户端和服务器继续缩略握手, 则它们照常从原始会话的主密钥派生新会话的连接密钥.

5.4. 互操作性考虑 (Interoperability Considerations)​

为了允许与旧版客户端和服务器互操作, TLS 对等方可以决定接受使用旧版主密钥计算的完整握手. 如果这样做, 它们需要通过向会话状态添加一个标志, 区分使用旧版主密钥的会话和使用扩展主密钥的会话.

如果客户端或服务器选择在没有扩展主密钥扩展的情况下继续完整握手, 则新会话会受到 第 1 节 中描述的中间人密钥同步攻击影响. 因此, 客户端或服务器 MUST NOT (禁止) 导出任何基于新主密钥的密钥材料, 用于任何后续应用层认证. 特别是, 它 MUST (必须) 禁用 [RFC5705], 以及任何依赖复合认证 (compound authentication) 的可扩展认证协议 (Extensible Authentication Protocol, EAP) [COMPOUND-AUTH].

如果客户端或服务器选择继续缩略握手以恢复未使用扩展主密钥的会话, 则当前连接会受到 第 1 节 所述的中间人握手日志同步攻击影响. 因此, 客户端或服务器 MUST NOT (禁止) 将当前握手的 verify_data 用于应用层认证. 特别是, 客户端 MUST (必须) 在当前连接上禁用重协商, 并禁用对 "tls-unique" 信道绑定 (channel binding) [RFC5929] 的任何使用.

如果原始会话使用扩展主密钥, 但缩略握手中的 ClientHello 或 ServerHello 未包含该扩展, 则继续缩略握手 MAY (可以) 是安全的, 因为它受到原始会话的扩展主密钥保护. 例如, 当实现此扩展的服务器建立了一个会话, 但随后该会话在另一个不支持此扩展的服务器上恢复时, 可能出现这种场景. 由于这类情况并不常见, 并且很可能是瞬时或无意配置错误造成的, 本文档建议客户端和服务器 MUST (必须) 中止这类握手.

最后于 更新