什么是防止中间人获取 SSL/TLS 密钥?

rya*_*sin 6 security https ssl

据我了解,在 HTTP 上使用 HTTPS 的主要原因是通信是加密的,因此任何监听的人都无法查看客户端/服务器之间 HTTP 交换的纯文本。

现在,在会话开始时,客户端和服务器会根据 SSL/TLS 握手期间获得的信息同意一个主密钥。但是什么是阻止某人使用客户端/服务器同意的相同密码套件来获取密钥呢?

如果没有什么可以阻止这种情况,那么 HTTPS 实际上比 HTTP 安全得多?MITM 所需要的只是使用从握手中获取的信息自己设计密钥,并使用它来解密客户端和服务器之间的通信。

我肯定错过了什么...

use*_*686 7

客户端和服务器仅就一个密钥达成一致,他们实际上从未以明文形式发送它。

最常见的是,使用DH 密钥交换( 2 ) 或其 ECDH 变体——每个对等方仅将其 DH 私钥与其他对等方的 DH 公钥结合起来,并获得相同的结果。如果您观察流量,您将只会看到两个对等方的公钥,这不足以导出生成的会话密钥。(TLS 握手稍后验证攻击者没有注入自己的公钥。)

另一种方法(现在很少见)是“静态 RSA”——在这种模式下,客户端自己生成会话密钥并使用服务器的公钥(从 SSL 证书获取)对其进行加密。虽然密钥通过网络发送的,但只有服务器能够解密它。

(虽然“静态 RSA”方法可能更简单,但也不太安全——获取证书的私钥将允许人们解密所有旧的和新的 HTTPS 会话;换句话说,没有前向保密。它也需要证书拥有一个能够加密/解密的密钥对,而 DH 风格的密钥派生只需要签名/验证。)

  • @Sinfieldd:ECDH 是最常见的。“常规”DH 和“静态 RSA”都在慢慢被淘汰,尽管仍有不少系统在使用。没有其他的,但最近谷歌浏览器已经开始试验 [CECPQ1 aka NewHope](https://bugs.chromium.org/p/chromium/issues/detail?id=626363) 密钥交换算法作为可能的 DH 更换。 (2认同)
  • 在 RSA 模式下,客户端生成主密钥,而不是会话密钥。 (2认同)