RFC 10015:在 TLS 1.2 和 DTLS 1.2 中不再推荐使用过时的密钥交换方法
1. 引言 (D)TLS 1.2 支持多种密钥交换算法,包括 RSA、在有限域上的 Diffie-Hellman (DH) 以及椭圆曲线 Diffie-Hellman (ECDH)。¶ DH 密钥交换有临时和非临时两种形式,适用于任何群体。非临时 DH 算法使用包含在认证对等方证书中的静态 DH 公钥;有关讨论,请参见 [ RFC4492 ] 。相反,临时 DH 算法使用在握手中发送的临时 DH 公钥,并通过对等方的证书进行认证。临时和非临时有限场 DH 算法分别称为 DHE 和 DH(或 FFDHE 和 FFDH);临时和非临时椭圆曲线 DH 算法分别称为 ECDHE 和 ECDH [ RFC4492 ] 。¶ 一般来说,由于缺乏前向保密性,不推荐使用非临时密码套件。此外,正如对有限场 DH 的浣熊攻击 [ RACCOON ] 所示,公共密钥重用(无论是通过非临时密码套件还是通过临时密码套件重用密钥)可能导致时序旁路,可能泄露连接密钥。对于 ECDH,无效的曲线攻击同样利用密钥重用以破坏安全性 [ ICA ] ,进一步证明了重用公共密钥的风险。虽然可以在实现中避免这两种旁路,但经验表明,在实践中,由于复杂性和所需缓解措施的数量,实施可能会未能阻止此类攻击。¶ 此外,RSA 密钥交换也面临安全问题,这些问题与实施选择无关,或纯粹由于正确实施安全对策的困难。¶ 粗略来看,影响 (D)TLS 1.2 中 FFDHE 的问题如下:¶ FFDHE 遇到互操作性问题,因为没有协商群体的机制,并且某些实现仅支持小群体大小(请参见 [ RFC7919 ],第 1 节)。¶ FFDHE 群体可能具有小子群,从而导致若干攻击 [ SUBGROUPS ] 。在面对一个自定义的非标准 FFDHE 群体时,握手客户端实际上无法验证服务器选择的群体是否存在此问题。也没有机制使得这些握手可以回退到客户端可以接受的其他密钥交换参数。自定义 FFDHE 群体非常普遍(这是基于 [ WEAK-DH ] 的建议的结果)。因此,客户端无法简单地拒绝提供自定义的,因此可能是危险的,群体的握手。¶ 在实践中,一些运营商使用 1024 位 FFDHE 群体,因为这是保证广泛支持的最大尺寸(请参见 [ RFC7919 ],第 1 节)。这个尺寸与当前的离散对数记录(795 位 [ DLOG795 ] )相比,仅留下少量安全余量。¶ 扩展之前的观点,少数非常大的计算就可以使攻击者便宜地解密相对较大部分的 FFDHE 流量(即,使用特定标准化群体加密的流量) [ WEAK-DH ]。¶ 当秘密不是完全临时时,FFDHE 遇到浣熊侧信道攻击 [ RACCOON ] 。(请注意,除非采用常量时间缓解措施,FFDHE 本质上容易受到浣熊攻击。)¶ 在 (D)TLS 1.2 中影响 RSA 密钥交换的问题如下:¶ 因构造原因,RSA 密钥交换没有前向保密性。¶ RSA 密钥交换可能会受到布莱辛巴赫攻击 [ BLEI ] 的影响。经验表明,这种攻击的变种每隔几年就会出现,因为正确实施相关的对策很困难(请参见 [ ROBOT ]、[ NEW-BLEI ] 和 [ DROWN ])。¶ 除上述观点外,在 (D)TLS 1.2 中没有方便的机制来进行密钥的域分隔。因此,单个易受布莱辛巴赫攻击的端点会影响所有共享相同 RSA 密钥的端点(请参见 [ XPROT ] 和 [ DROWN ])。¶ 本文档更新了 [ RFC4162 ]、[ RFC4279 ]、[ RFC4346 ]、[ RFC4785 ]、[ RFC5246 ]、[ RFC5288 ]、[ RFC5289 ]、[ RFC5469 ]、[ RFC5487 ]、[ RFC5932 ]、[ RFC6209 ]、[ RFC6347 ]、[ RFC6367 ]、[ RFC6655 ]、[ RFC7905 ]、[ RFC8422 ] 和 [ RFC9325 ] 来修正上述问题,方法是不再推荐和劝阻使用受到影响的密码套件,如第 5.2、5.3、5.4 和 5.5 节所列。¶ BCP 195 [ RFC8996 ] [ RFC9325 ] 包含了 IETF 对 (D)TLS 协议用户(尤其是 (D)TLS 1.2)的最新建议,并且本文档在多个点上更新了 [ RFC9325 ]。第 6 节详细说明了确切的差异。其他在 BCP 文档中的建议仍然有效。¶ 1.1. 要求语言 本文件中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按照 BCP 14 [ RFC2119 ] [ RFC8174 ] 中的描述进行解释,仅当它们以大写字母出现时,如此处所示。
本站免费、广告极少。如果觉得有帮助,可以请我们喝杯咖啡 —— 任何金额都对持续运营有实际帮助。
☕请我喝杯咖啡