【HTTPS】HTTPS ECDHE握手解析

HTTPS常用的密钥交换算法有两种，分别是RSA和ECDHE算法。

其中，RSA是比较传统的密钥交换算法，它不具备前向安全的性质，因此现在很少服务器使用它。而ECDHE算法具有前向安全，所以被广泛使用。

离散对数

ECDHE秘要协商算法是DH算法严禁过来的，所以我们先从DH算法说起。

DH算法是非对称算法，因此它可以用于秘钥交换，该算法的核心数学思想是离散对数。

离散对数是【离散+对数】的两个数学概念的组合。对数和指数互为反函数。

对数运算的取值是可以连续的，而离散对数的取值是不能连续的，因此也以【离散】得名。

离散对数是在对数运算的基础上加了模运算，也就是取余数，对应编程语言的操作符是%，也可以用mod表示。如下所示：

其中，如果对于一个整数b和质数p的一个原根a，可以找到一个唯一的指数i，使得：

a^i (mod p) = b

成立，那么指数i称为b的以a为底的模p的离散对数。其中，底数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。

然后执行运算：

小红：K=B^a mod p
小明：K=A^b mod p

这个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椭圆曲线特性，可以用更少的计算量计算出公钥，以及最终的会话秘钥。

小红和小明使用ECHDE秘钥交换算法的过程：

1. 双方事先确定好使用哪种椭圆曲线，和曲线上的基点G，这两个参数都是公开的；
2. 双方各自随机生成一个随机数作为私钥d，并与基点G相乘得到公钥Q(Q=dG),此时小红的公私钥为Q1和d1，小明的公私钥为Q2和d2.
3. 双方交换各自的公钥，最后小红计算点(x1,y1)=d1Q2,小明计算点(x2,y2)=d2Q1，由于椭圆曲线上是可以满足乘法交换和结合律，所以d1Q2 = d1d2G = d2d1G = d2Q1，因此双方的x坐标是一样的，所以它是共享密钥，也就是会话密钥。

这个过程中，双方的私钥都是随机的，临时生成的，都是离不开的，即使根据公开的信息（椭圆曲线、公钥，基点G）也是很难计算出椭圆曲线上的离散对数（私钥）。

ECDHE握手过程

我们可以看到，用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消息。

 这个过程服务器做了三件事：

• 选择了名为x25519的椭圆曲线，选好了椭圆曲线相当于椭圆曲线基点G也订好了，这些都会公开给客户端；
• 生成随机数作为服务端椭圆曲线的私钥，保留到本地；
• 根据基点G和私钥计算出服务端的椭圆曲线公钥，这个会公开给客户端。

为了保证这个椭圆曲线的怪咖不被第三方篡改，服务端会用RSA签名算法给服务端的椭圆曲线公钥做个签名。

随后，就是Server Hello Done消息，服务端跟客户端表明："打招呼完毕”.

至此，TLS两次握手就已经完成了，目前客户端和服务端通过明文共享了这几个信息：Client Random/ Server Random、使用的椭圆曲线、椭圆曲线基点G、服务端椭圆曲线的公钥，这几个信息很重要，是后续生成会话秘钥的材料。

TLS第三次握手

客户端收到了服务端的证书后，自然要校验证书是否合法，如果证书合法，那么服务端到身份就是没问题的，校验证书的过程回走证书链逐级验证，确认证书的真实性，再用证书的公钥验证签名，这样就能确认服务端的身份了，确认无误后，就可以继续往下走。

客户端会生成一个随机数作为客户端椭圆曲线的私钥，然后在根据服务端前面给的信息，生成客户端的椭圆曲线公钥，然后用Client Key Exchang消息发给服务端。

至此，双方都有对方的椭圆曲线公钥、自己的椭圆曲线私钥、椭圆曲线基点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握手过程没有该消息。