本文转载自微信公众号「 小林coding」，作者 小林coding。请联系 小林转载本文coding公众号。
HTTPS 有两种常用的密钥交换算法，即 RSA 和 ECDHE 算法。
其中，RSA 是一种传统的密钥交换算法，不具有前向安全性，所以现在很少使用服务器。ECDHE 算法具有前向安全性，因此得到了广泛的应用。
我在上一篇已经介绍了 RSA 握手的过程，今天的文章「从理论到实战抓包」介绍 ECDHE 算法。
离散对数
ECDHE 密钥协商算法是 DH 算法演变而来，所以我们先从 DH 算法说起。
DH 算法是非对称加密算法，因此可用于密钥交换，其核心数学思想是离散对数。
听到这个数学概念会怂吗？不怕，这次不会说离散对数推的过程，简单提一下它的数学公式。
离散对数是「分散 对数」两个数学概念的组合，让我们先复习对数。
说到对数，必须说指数，因为它们是相互的反函数，指数是功率操作，对数是指数的反操作。
以 2 为底数的栗子，如下图所示：
当底数为 2 时，32 对数为 5，64 对数为 6，计算过程如下：
对数运算的值可以连续，离散对数的值不能连续，所以也可以「离散」得名，
在对数运算的基础上增加了离散对数「模运算」，也就是说，对应编程语言的操作符是取余数「%」，也可以用 mod 表示。离散对数的概念如下图所示：
上图，底数 a 和模数 p 是离散对数的公共参数，也就说是公开的，b 是真数，i 是对数。如果你知道对数，你可以用上面的公式计算真数。但另一方面，知道真数很难计算对数。
特别是当模数 p 是一个很大的质数，即使你知道底数 a 和真数 b ，在现有计算机的计算水平上，离散对数几乎无法计算，即 DH 算法的数学基础。
DH 算法
了解了离散对数，我们来看看 DH 如何用密钥交换算法。
假设小红和小明同意使用 DH 算法交换密钥，所以基于离散对数，小红和小明需要确定模数和底数作为算法的参数，这两个参数是公开的P 和 G 来代称。
然后小红和小明生成一个随机整数作为私钥。双方的私钥应严格保管，不得泄漏。小红的私钥用 a 代表小明的私钥使用 b 代称。
现在小红和小明都有 P 和 G 及其各自的私钥，因此可以计算公钥：
- 记录小红的公钥 A，A = G ^ a ( mod P );
- 记录小明的公钥 B，B = G ^ b ( mod P );
A 和 B 也是公开的，因为根据离散对数的原理，从真数(A 和 B)反向计算对数 a 和 b 非常困难。至少现有计算机的计算能力无法破解。如果量子计算机出来，它可能会被破解。当然，如果量子计算机真的出来了，那么密钥协商算法将得到更大的升级。
双方交换 DH 公钥后，小红手上有 5 数：P、G、a、A、B，小明手里也有 5 个数:P、G、b、B、A。
然后小红执行操作:B ^ a ( mod P )，结果是 K，由于离散对数的幂运算有交换律，小明执行运算：A ^ b ( mod P )，结果也是 K。
这个 K 是小红和小明之间使用的对称加密钥，可作为会话钥匙使用。
在整个密钥谈判过程中，小红和小明公开了 4 信息：P、G、A、B，其中 P、G 是算法的参数，A 和 B 是公钥， a、b 是双方保管的私钥，黑客无法获得这个 2 私钥，所以黑客只能从公开 P、G、A、B 开始计算离散对数(私钥)。
前面也多次强调，根据离散对数的原理，如果 P 是一个大数字，现有计算机的计算能力很难破解 私钥 a、b ，如果你不能破解私钥，你就不能计算会话密钥，所以 DH 密钥交换是安全的。
DHE 算法
根据私钥生成的方式，DH 算法分为两种实现：
- static DH 算法，这被废弃；
- DHE 算法，现在常用；
static DH 算法中一方的私钥是静态的，也就是说，每次密钥协商时，一方的私钥是一样的，通常由服务器固定，即 a 不变，客户端私钥随机生成。
于是，DH 交换密钥时，只有客户端的公钥发生变化，服务端的公钥不变。随着时间的推移，黑客将截获大量密钥协商过程中的数据。由于密钥协商过程中的一些数据是公开的，黑客可以根据这些数据暴力破解服务器的私钥，然后计算会话密钥，因此之前截获的加密数据将被破解，因此 static DH 算法没有前向安全性。
由于固定一方的私钥有被破解的风险，只需让双方的私钥在每次密钥交换通信时随机生成和临时，即 DHE 算法，E 全称是 ephemeral(临时)。
因此，即使一个强大的黑客破解了某个通信过程的私钥，其他通信过程的私钥仍然是安全的，因为每个通信过程的私钥都是独立的，这是有保证的「前向安全」。
ECDHE 算法
DHE 算法为了提高 DHE 算法的性能因此被广泛应用于密钥交换算法 —— ECDHE 算法。
ECDHE 算法是 DHE在 算法的基础上，使用了 ECC 椭圆曲线特性，公钥和最终会话密钥可以用较少的计算量计算。
小红和小明用 ECDHE 密钥交换算法的过程：
- 双方提前确定使用哪种椭圆曲线，曲线上的基点 G，这两个参数都是公开的；
- 双方随机生成随机数作为私钥d，并与基点 G相乘得到公钥Q(Q = dG)，这时，小红的公私钥是 Q1 和 d1，小明的公私钥是 Q2 和 d2;
- 双方交换公钥，最后小红计算点(x1，y1) = d1Q2，小明计算点(x2，y2) = d2Q1， d1Q2 = d1d2G = d2d1G = d2Q1因此，双方的 x 坐标是一样的，所以它是共享密钥，即会话密钥。
在这个过程中，双方的私钥是随机和临时生成的，即使根据公共信息(椭圆曲线、公钥、基点 G)椭圆曲线上的离散对数(私钥)也很难计算。
ECDHE 握手过程
知道了 ECDHE 算法的基本原理结合实际情况。
我用 Wireshark 用 抓住工具ECDHE 关键协商算法的 TSL 握手时可以看到四次握手:
细心的朋友应该发现，使用 ECDHE，在 TLS 在第四次握手之前，客户端已经发送了加密 HTTP 数据，而 RSA 必须完成 握手过程TLS 四次握手，传输应用数据。
所以，ECDHE 相比 RSA 握手过程省去了一个消息往返的时间，这个有点「抢跑」它叫是的「TLS False Start」，跟「TCP Fast Open」有点像，在连接完全建立之前，就发送了应用数据，从而提高了传输效率。
接下来，分析每个 ECDHE 握手过程。
TLS 第一次握手
客户端会先发一个「Client Hello」消息中有客户端使用的 TLS 版本号、支持的密码套件列表，生成的随机数(Client Random)。
TLS 第二次握手
接收客户端的服务端「打招呼」，也要回礼，会回礼「Server Hello」新闻，服务器确认的 TLS 版本号也给出了随机数(Server Random)，然后从客户端的密码套件列表选择了一个合适的密码套件。
然而，这次选择的密码套件和 RSA 不一样。我们来分析一下这个密码套件的含义。
「 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384」
- 用于密钥协商算法ECDHE;
- 使用 签名算法RSA;
- 通信使用 握手后AES 对称算法，密钥长度 256 位，分组模式为 GCM;
- 使用 摘要算法SHA384;
然后，为了证明自己的身份，服务端发送「Certificate」该消息还将向客户送证书。
这一步和 RSA 握手过程非常不同，因为服务端选择了 ECDHE 密钥协商算法，发送证书后会发送「Server Key Exchange」消息。
服务器做了三件事：
- 选择了名为 named_curve 选择的椭圆曲线相当于 G 也定好了，这些都会公开给客户端；
- 作为服务端椭圆曲线的私钥生成随机数，保留在本地；
- 根据基点 G 和私钥计算服务端的椭圆曲线公钥，将向客户端公开。
为确保椭圆曲线的公钥不被第三方篡改，服务端将使用 RSA 签名算法为服务端的椭圆曲线公钥签名。
随后，就是「Server Hello Done」服务端和客户端表示：“这些是我提供的信息。打招呼后”。
至此，TLS 两次握手已经完成。目前，客户端和服务端通过明文共享了这些信息：Client Random、Server Random ，使用的椭圆曲线，椭圆曲线基点 G、这些信息对于服务端椭圆曲线的公钥非常重要，是后续生成会话密钥的材料。
TLS 第三次握手
客户端收到了服务端的证书后，自然要校验证书是否合法，如果证书合法，那么服务端到身份就是没问题的。校验证书到过程，会走证书链逐级验证，确认证书的真实性，再用证书的公钥验证签名，这样就能确认服务端的身份了，确认无误后，就可以继续往下走。
客户端将生成随机数作为客户端椭圆曲线的私钥，然后根据服务端前面提供的信息生成客户端椭圆曲线的公钥，然后使用「Client Key Exchange」给服务端发消息。
到目前为止，双方都有对方的椭圆曲线公钥、自己的椭圆曲线私钥、 椭圆曲线基点G。因此，双方都计算出点(x，y)，其中 x 坐标值双方都一样，前面说 ECDHE 算法时，说 x 是会话密钥，但在实际应用中，x 不是最后的会话密钥。
还记得 TLS 在握手阶段，客户端和服务端会生成随机数传递给对方吗？
最后的会话密钥是使用「客户端随机数量 服务端随机数量 x(ECDHE 算法算出的共享密钥) 」三种材料。
之所以这么麻烦，是因为 TLS 设计师不信任客户端或服务器「伪随机数」为了保证三个不可靠的随机数量的真正完全随机混合，那么「随机」程度很高，足以让黑客计算出最终的会话密钥，安全性更高。
计算会话密钥后，客户端会发送一个「Change Cipher Spec」新闻告诉服务端后续对称算法加密通信。
然后，客户端会发送「Encrypted Handshake Message」新闻，总结之前发送的数据，然后用对称密钥加密，让服务器进行验证，验证生成的对称密钥是否可以正常使用。
TLS 第四次握手
最后，服务端也会有同样的操作，头发「Change Cipher Spec」和「Encrypted Handshake Message」新闻，如果双方都验证加密和解密没有问题，会正式完成。因此，加密 可以正常收发HTTP 请求和响应了。
总结
RSA 和 ECDHE 握手过程的区别:
- RSA 密钥协商算法「不支持」前向保密，ECDHE 密钥协商算法「支持」前向保密;
- 使用了 RSA 密钥协商算法，TLS 只有在完成四次握手后，才能传输应用数据。ECDHE 算法，客户端不需要等待服务端的最后一次 TLS 握手，可以提前发出加密 HTTP 数据节省了消息的往返时间；
- 使用 ECDHE，在 TLS 第 2 次握手时，服务器端会发出「Server Key Exchange」消息，而 RSA 握手过程中没有消息；
巨人的肩膀
https://zh.wikipedia.org/wiki/椭圆曲线迪菲-赫尔曼金钥交换
https://zh.wikipedia.org/wiki/椭圆曲线
https://zh.wikipedia.org/wiki/迪菲-赫尔曼密钥交换
https://time.geekbang.org/column/article/148188
https://zhuanlan.zhihu.com/p/106967180
原文链接：https://mp.weixin.qq.com/s/pLyR8zuw4l7Z6sdUZ4IL5w