ssl证书 三种解密 HTTPS 流量的方法介绍(2)

Client Random 和 Server Random 明文传输，中间人可以直接查看。客户端生成 Premaster Secret 后，用服务端证书公钥加密后发送，如果服务端拥有对应的私钥，就可以成功解密得到 Premaster Secret。这时，客户端和服务端拥有相同的 Client Random、Server Random 和 Premaster Secret，可以各自算出相同的后续所需 Key。

可以看到，这种方式合并了密钥交换和服务端认证两个步骤，如果服务端能解密 Premaster Secret，也就意味着服务端拥有正确的私钥。中间人没有私钥，无法得到 Premaster Secret，也就无法解密后续流量。

对于 Wireshark 来说，配置某个网站的私钥后，能解密这个网站「使用 RSA 进行密钥交换」的加密流量就很容易理解了。

显然，RSA 密钥交换有一个很大的问题：没有前向安全性Forward Secrecy。这意味着攻击者可以把到的加密流量先存起来，后续一旦拿到了私钥，之前所有流量都可以成功解密。

实际上，目前大部分 HTTPS 流量用的都是 ECDHE 密钥交换。ECDHE 是使用椭圆曲线（ECC）的 DH（Diffie-Hellman）算法。下图是 DH 密钥交换过程：

上图中的 Server DH Parameter 是用证书私钥签名的，客户端使用证书公钥就可以验证服务端合法性。相比 RSA 密钥交换，DH 由传递 Premaster Scret 变成了传递 DH 算法所需的 Parameter，然后双方各自算出 Premaster Secret。

对于这种情况，由于 Premaster Secret 无需交换，中间人就算有私钥也无法获得 Premaster Secret 和 Master Secret。也就是说 Wireshark 无法通过配置 RSA Private Key 的方式解密「使用 ECDHE 进行密钥交换」的加密流量。当然，使用 ECDHE 后，虽然中间人拿到私钥也无法解密之前的流量，但他可以实施 MITM 攻击来解密之后的流量，所以私钥还是要保管好。

相比 RSA 既可以用于密钥交换，又可以用于数字签名；ECC 这边就分得比较清楚了：ECDHE 用于密钥交换，ECDSA 用于数字签名。也就是目前密钥交换 + 签名有三种主流选择：

RSA 密钥交换、RSA 数字签名；

ECDHE 密钥交换、RSA 数字签名；

ECDHE 密钥交换、ECDSA 数字签名；

以下是使用这三种密钥交换方式的网站在 Chrome 中的截图：

key exchange

HTTP/2 中只能使用 TLSv1.2+，还禁用了几百种 CipherSuite（详见：）。实际上，HTTP/2 允许使用的 CipherSuite 必须采用具有前向安全性的密钥交换算法，不允许使用 RSA 密钥交换。这也是为什么 RSA Private Key 无法解密 HTTP/2 加密流量。

Firefox 和 Chrome 都会在系统环境变量存在SSLKEYLOGFILE文件路径时，将每个 HTTPS 连接产生的 Premaster Secret 或 Master Secret 存下来。有了这个文件，Wireshark 就可以轻松解密 HTTPS 流量，即使是使用了 ECDHE 这种具有前向安全性的密钥交换，如下图：

decrypt http2 over tls

这种方案的详细介绍请参考「使用 Wireshark 调试 HTTP/2 流量」这篇文章。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-59334-2.html