HTTPS 过程
协商过程.png

Https抓包 - 图2

image.png
wireshark没有ssl协议？
直接抓443端口吧
tcp.port==443 过滤条件

image.png

前三个是TCP三次握手
整个过程：

  1. 客户端发送 Client Hello 消息给服务端；
  2. 服务端回应 Server Hello 消息；
  3. 服务端同时回应 Server Certificate、Server Key Exchange 和 Server Hello Done 消息；
  4. 客户端发送 Client Key Exchange、Change Cipher Spec 和 Client Finished 消息；
  5. 服务端最后发送 Change Cipher Spec 和 Server Finished 消息；

Client Hello

发送一个随机数？
image.png
别人的记录：
Https抓包 - 图6

Server Hello

又返回一个随机数
image.png

Https抓包 - 图8

服务端同时回应 Certificate、Server Key Exchange 和 Server Hello Done 消息；

我抓的包确实是分开的

image.png

Certifacate中的证书认证：
image.png

Server Key Exchange中
image.png
从 Server Key Exchange 消息可以看出双方密钥协商使用的是 Diffie-Hellman (迪菲) 算法，该消息用于传递 Diffie-Hellman (迪菲) 算法的参数。

客户端发送 Client Key Exchange、Change Cipher Spec 和 Client Finished 消息

这次确实是一起的

image.png
客户端同时回复了 3 个消息：Client Key Exchange、Change Cipher Spec 和 Client Finished 消息。Client Key Exchange 的内容为 Diffie-Hellman (迪菲) 算法的参数，用于生成 premaster key，然后和双方之前的随机数结合生成对称密钥。

Client Key Exchange
Diffie-Hellman (迪菲) 算法的参数
image.png

服务端Change Cipher Spec 和 Server Finished

服务端最后发送Change Cipher Spec 和 Server Finished 消息，至此 SSL/TLS 握手完毕，接下来双方会用对称加密的方式加密传输数据。

image.png

除去协议的协商这些，最重要的就是

C向S发送一个随机数 —-1
S向C发送一个随机数 —-2
S向C发送证书
S向C发送DH的参数 —-3
C向S发送DH的参数 —-4

目的：

C想要 获得 经过 CA私钥签名 的 S 的公钥

C获得这个公钥后，把一个随机数用这个公钥加密，然后发给S，S用私钥解密以后就得到了他们以后进程对称加密的key

那么为什么 HTTPS用到了这么多随机数？

因为这个算法！！！就是想用三个随机数确定一个随机数！！！！

上面步骤3，4是DH算法计算出一个随机数
然后，客户端跟服务端手中都有三个随机数，就可以确定一个对称加密用的随机数！！！！！！！！！！！！！！