TLS四次握手

tls

第一次握手

1. 客户端发送client hello消息：tls版本号，支持的密码条件列表，以及生成的随机数。

字段	说明
tls版本号	客户端支持的版本号
密码套件	客户端支持的密码套件：支持哪些加密算法
生成随机数	客户端生成64位随机字符串

第二次握手

第二次握手之server hello
服务端收到消息后，返回server hello，

不过，这次选择的密码套件就和 RSA 不一样了，我们来分析一下这次的密码套件的意思。

Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)

密钥协商算法使用：ECDHE
签名算法使用：ECDSA
握手后使用通信算法：AES对称算法，密钥长度：128位，分组模式：GCM
摘要算法：SHA256

第二次握手之下发证书

服务端为了证明自己的身份，发送「Certificate」消息，会把证书也发给客户端。

第二次握手之服务器交换密钥

因为服务端选择了 ECDHE 密钥协商算法，所以会在发送完证书后，发送「Server Key Exchange」消息。

这个过程服务器做了三件事：
● 选择了名为 named_curve 的椭圆曲线，选好了椭圆曲线相当于椭圆曲线基点 G 也定好了，这些都会公开给客户端；
● 生成随机数作为服务端椭圆曲线的私钥，保留到本地；
● 根据基点 G 和私钥计算出服务端的椭圆曲线公钥，这个会公开给客户端。
为了保证这个椭圆曲线的公钥不被第三方篡改，服务端会用 RSA 签名算法给服务端的椭圆曲线公钥做个签名。
随后，就是「Server Hello Done」消息，服务端跟客户端表明：“这些就是我提供的信息，打招呼完毕”。

第三次握手

第三次握手之Client Key Exchange

客户端收到了服务端的证书后，自然要校验证书是否合法，如果证书合法，那么服务端到身份就是没问题的。校验证书到过程，会走证书链逐级验证，确认证书的真实性，再用证书的公钥验证签名，这样就能确认服务端的身份了，确认无误后，就可以继续往下走。
客户端会生成一个随机数作为客户端椭圆曲线的私钥，然后再根据服务端前面给的信息，生成客户端的椭圆曲线公钥，然后用「Client Key Exchange」消息发给服务端。

至此，双方都有对方的椭圆曲线公钥、自己的椭圆曲线私钥、椭圆曲线基点 G。于是，双方都就计算出点（x，y），其中 x 坐标值双方都是一样的，前面说 ECDHE 算法时候，说 x 是会话密钥，但实际应用中，x 还不是最终的会话密钥。
还记得 TLS 握手阶段，客户端和服务端都会生成了一个随机数传递给对方吗？
最终的会话密钥，就是用「客户端随机数 + 服务端随机数 + x（ECDHE 算法算出的共享密钥） 」三个材料生成的。
之所以这么麻烦，是因为 TLS 设计者不信任客户端或服务器「伪随机数」的可靠性，为了保证真正的完全随机，把三个不可靠的随机数混合起来，那么「随机」的程度就非常高了，让黑客计算不出最终的会话密钥，安全性更高。

第三次握手之Change Cipher Spec

第四次握手

最后，服务端也会有一个同样的操作，发「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双方都验证加密和解密没问题，那么握手正式完成。于是，就可以正常收发加密的 HTTP 请求和响应了。

第四次握手，在wireshark中没有找到

参考地址：

图解 ECDHE 密钥交换算法

https://www.likecs.com/show-124371.html