9. 安全考虑 (Security Considerations)
所有适用于 TLS 的安全考虑也适用于 QUIC 中 TLS 的使用. 阅读 [TLS13] 及其附录的全部内容是了解 QUIC 安全属性的最佳方式.
本节总结了特定于 TLS 集成的一些更重要的安全方面,尽管文档的其余部分中有许多与安全相关的细节.
9.1. 会话可链接性 (Session Linkability)
使用 TLS 会话票据 (Session Tickets) 允许服务器和可能的其他实体关联同一客户端建立的连接; 有关详细信息,请参见第 4.5 节.
9.2. 0-RTT 重放攻击 (Replay Attacks with 0-RTT)
如 [TLS13] 的第 8 节所述,使用 TLS 早期数据会暴露于重放攻击. QUIC 中使用 0-RTT 同样容易受到重放攻击.
端点必须 (MUST) 实现并使用 [TLS13] 中描述的重放保护,但是应认识到这些保护是不完美的. 因此,需要额外考虑重放的风险.
QUIC 不易受到重放攻击,除非通过它可能承载的应用协议信息. 基于 [QUIC-TRANSPORT] 中定义的帧类型的 QUIC 协议状态管理不易受到重放攻击. QUIC 帧的处理是幂等的 (Idempotent),如果帧被重放、重新排序或丢失,不会导致无效的连接状态. QUIC 连接不会产生超出连接生命周期的影响,除了 QUIC 服务的应用协议产生的影响.
TLS 会话票据和地址验证令牌 (Address Validation Tokens) 用于在连接之间承载 QUIC 配置信息,特别是为了使服务器能够高效地恢复连接建立和地址验证中使用的状态. 这些禁止 (MUST NOT) 用于在端点之间传递应用语义; 客户端必须 (MUST) 将它们视为不透明值. 这些令牌的潜在重用意味着它们需要更强的重放保护.
接受连接上 0-RTT 的服务器比接受没有 0-RTT 的连接承担更高的成本. 这包括更高的处理和计算成本. 服务器在接受 0-RTT 时需要考虑重放的概率和所有相关成本.
最终,管理 0-RTT 重放攻击风险的责任在于应用协议. 使用 QUIC 的应用协议必须 (MUST) 描述协议如何使用 0-RTT 以及采用哪些措施来防止重放攻击. 重放风险分析需要考虑所有承载应用语义的 QUIC 协议功能.
完全禁用 0-RTT 是防御重放攻击的最有效方法.
QUIC 扩展必须 (MUST) 描述重放攻击如何影响其操作或禁止在 0-RTT 中使用该扩展. 应用协议必须 (MUST) 禁止在 0-RTT 中使用承载应用语义的扩展,或提供重放缓解策略.
9.3. 数据包反射攻击缓解 (Packet Reflection Attack Mitigation)
导致服务器发送大量握手消息块的小型 ClientHello 可用于数据包反射攻击以放大攻击者生成的流量.
QUIC 包含三种针对此攻击的防御. 首先,包含 ClientHello 的数据包必须 (MUST) 填充到最小大小. 其次,如果响应未验证的源地址,则禁止服务器发送超过其接收字节数三倍的字节(参见 [QUIC-TRANSPORT] 的第 8.1 节). 最后,由于握手数据包的确认经过身份验证,盲攻击者 (Blind Attacker) 无法伪造它们. 综合起来,这些防御限制了放大级别.
9.4. 包头保护分析 (Header Protection Analysis)
[NAN] 分析了提供随机数隐私 (Nonce Privacy) 的认证加密算法,称为"隐藏随机数" (Hide Nonce, HN) 转换. 本文档中的通用包头保护构造是这些算法之一 (HN1). 包头保护在数据包保护 AEAD 之后应用,从 AEAD 输出中采样一组字节 ("sample"),并使用伪随机函数 (Pseudorandom Function, PRF) 加密包头字段,如下所示:
protected_field = field XOR PRF(hp_key, sample)
本文档中的包头保护变体使用伪随机排列 (Pseudorandom Permutation, PRP) 代替通用 PRF. 但是,由于所有 PRP 也是 PRF [IMC],这些变体不偏离 HN1 构造.
由于 "hp_key" 与数据包保护密钥不同,因此包头保护实现了 [NAN] 中定义的 AE2 安全性,从而保证了 "field"(受保护的数据包头) 的隐私性. 基于此构造的未来包头保护变体必须 (MUST) 使用 PRF 以确保等效的安全保证.
使用相同的密钥和密文样本多次存在损害包头保护的风险. 使用相同密钥和密文样本保护两个不同的包头会揭示受保护字段的异或. 假设 AEAD 充当 PRF,如果采样 L 位,则两个密文样本相同的概率接近 2^(-L/2),即生日界限 (Birthday Bound). 对于本文档中描述的算法,该概率为 2^64 分之一.
为了防止攻击者修改数据包头,包头使用数据包保护进行传递性身份验证 (Transitively Authenticated); 整个数据包头是经过身份验证的关联数据的一部分. 被伪造或修改的受保护字段只能在移除数据包保护后才能检测到.
9.5. 包头保护时序侧信道 (Header Protection Timing Side Channels)
攻击者可以猜测包编号或密钥阶段 (Key Phase) 的值,并让端点通过时序侧信道确认猜测. 类似地,可以尝试对包编号长度的猜测并暴露. 如果数据包接收方在不尝试移除数据包保护的情况下丢弃具有重复包编号的数据包,它们可能会通过时序侧信道揭示包编号与接收到的数据包匹配. 为了使身份验证不受侧信道影响,包头保护移除、包编号恢复和数据包保护移除的整个过程必须 (MUST) 一起应用,没有时序和其他侧信道.
对于数据包的发送,数据包负载和包编号的构造和保护必须 (MUST) 不受会揭示包编号或其编码大小的侧信道影响.
在密钥更新期间,生成新密钥所花费的时间可能会通过时序侧信道揭示已发生密钥更新. 或者,当攻击者注入数据包时,此侧信道可能会揭示注入数据包上密钥阶段的值. 在收到密钥更新后,端点应该 (SHOULD) 生成并保存下一组接收数据包保护密钥,如第 6.3 节所述. 通过在收到密钥更新之前生成新密钥,数据包的接收不会创建泄漏密钥阶段值的时序信号.
这取决于不在数据包处理期间执行此密钥生成,并且可能要求端点为接收维护三组数据包保护密钥: 用于先前密钥阶段、当前密钥阶段和下一个密钥阶段. 端点可以选择推迟生成下一个接收数据包保护密钥,直到它们丢弃旧密钥,以便在任何时间点只需要保留两组接收密钥.
9.6. 密钥多样性 (Key Diversity)
在使用 TLS 时,使用 TLS 的中央密钥调度 (Key Schedule). 由于 TLS 握手消息被集成到密钥的计算中,包含 QUIC 传输参数扩展可确保握手和 1-RTT 密钥与运行 TCP 上 TLS 的服务器可能生成的密钥不同. 为了避免跨协议密钥同步的可能性,提供了额外的措施来改进密钥分离.
QUIC 数据包保护密钥和 IV 使用与 TLS 中等效密钥不同的标签派生.
为了保持这种分离,新版本的 QUIC 应该 (SHOULD) 为数据包保护密钥和 IV 的密钥派生以及包头保护密钥定义新标签. 此版本的 QUIC 使用字符串 "quic". 其他版本可以使用特定于版本的标签代替该字符串.
初始密钥 (Initial Secrets) 使用特定于协商的 QUIC 版本的密钥. 新 QUIC 版本应该 (SHOULD) 定义用于计算初始密钥的新盐值.
9.7. 随机性 (Randomness)
QUIC 依赖于端点能够生成安全随机数,既直接用于连接 ID 等协议值,也通过 TLS 间接使用. 有关安全随机数生成的指导,请参见 [RFC4086].