根据TLS 1.3 规范的第二稿,自定义 DH 组已被弃用。众所周知,硬编码的 DH 组容易受到允许追溯解密的预计算攻击。由于 TLS 1.3 并没有完全弃用 DH 进行密钥交换,我想这意味着它将退回到标准组(例如 Oakley 组)。考虑到这一点,为什么 TLS 1.3 会弃用自定义 DH 组?为什么不做相反的事情并弃用标准组,甚至弃用所有 DH 密钥交换来为 ECC 让路?
为什么 TLS 1.3 不推荐使用自定义 DHE 组?
信息安全
tls
密码学
协议
密钥交换
diffie-hellman
2021-09-01 04:49:08
1个回答
使用 TLS 1.2,服务器首先需要在 ServerKeyExchange 消息中告诉客户端它支持的 DHE 组的参数。只有这样,客户才能对这些采取行动。使用 TLS 1.3,客户端从一开始就从一组命名组中进行选择。由于客户端现在选择组而不是服务器,因此可以立即开始密钥交换(从一开始就知道所有信息),这从握手中减少了完整的 RTT,从而提高了性能。
当然,理论上人们仍然可以通过这种方式自定义组,只是客户端这次定义了这些组,而不是服务器。我找不到任何具体信息为什么要删除自定义组,但根据TLS 邮件列表中的此消息,它似乎发生在 2014 年中期的一些临时会议期间。我在 03/2014 的正式会议和 07/2014的下一次会议上找不到任何有关此的信息。
但是,论文Indiscreet Logs: Persistent Diffie-Hellman Backdoors in TLS from 2016 中的一些信息可能指向正确的方向。本文讨论了使用自定义 DH 组和在VII 中的可否认后门。讨论 A. 缓解策略讨论了各种策略来防止此类后门,例如完全禁用 DHE 或仅使用已知良好(命名)的 DH 组,类似于使用 ECC 所做的。如果完全删除 DHE 不是一个选项,那么拥有一组固定的命名 DHE 参数似乎是处理此问题的最简单方法。
其它你可能感兴趣的问题