基于TASSL双向认证握手协议
说明
C->S表示报文从client端发送到server端
S->C表示报文从server端发送到client端。
采用国密版本wirshark进行抓包操作。
1 client hello （C->S）
客户端发起握手协商操作，它将发送一个 Client Hello 消息给服务器，消息中明确了其所支持的SSL/TLS版本、Cipher suite加密算法组合等，可以让服务器选择，并提供了一个客户端随机数，用于以后生成会话密钥使用。
2 server hello （S->C）
服务器将返回一个 Server Hello 消息，该消息包含了服务器选择的协议版本、加密算法，以及服务器随机数、会话ID等内容。其中，服务器选择的协议版本应小于等于客户端Client Hello中的协议版本。
3 Certificate （S->C）
服务器发送Server Hello消息，选择好协议版本和加密算法组合后，将发送 Certificate 消息，该消息包含了服务器的证书等信息，可通过证书链认证该证书的真实性。根据选择的加密算法组合的不同，服务器证书中的公钥也可被用于加密后面握手过程中生成的Premaster secret。
4 Server Key Exchange（S->C）
对于标准协议来说是用来进行椭圆曲线协调的，但是国密并不会真正采用椭圆曲线的秘钥协商算法。仍旧是采用传统的DH秘钥协商算法。
5 Certificate request （S->C）
双向认证要求客户端发来证书
6 Server Hello Done（S->C）
7 Certificate（C->S）
因为server要求验证证书，发送了Certificate request ，client在收到该报文后，将自己的证书发送到了服务端。
8 Client Key Exchange（C->S）
客户端发送 Client Key Exchange消息，将自己的Diffie-Hellman协议中的Pub Key发送到服务端。
9 Certificate verify C->S
发送这个类型的握手需要2个前提条件
服务器端请求了客户端证书
客户端发送了非0长的证书
此时，客户端想要证明自己拥有该证书，必然需要私钥签名一段数据发给服务器验证。
签名的数据是客户端发送certificate verify前，所有收到和发送的握手信息（不包括5字节的record）。其实这个流程和签名server key exchange基本一样。计算摘要，然后签名运算。
10 Change Cipher Spec（C->S）
加密传输中每隔一段时间必须改变其加解密参数的协议，因为后续的报文都会采用刚刚协商好的加密秘钥进行加密传输，因此会发送该报文。
11 Encrypted handshake Message（C->S）
该报文的目的就是，客户端告诉服务端，自己在整个握手过程中收到了什么数据，发送了什么数据。来保证中间没人篡改报文。
该数据采用刚才协商好的秘钥进行加密，顺带验证秘钥。
12 New Session ticket（S->C）
一种控制后续交互数据量和数据有效值的session设置，这里可能不会生效。
参考阅读
13 Change Cipher Spec （S->C）
加密传输中每隔一段时间必须改变其加解密参数的协议，因为后续的报文都会采用刚刚协商好的加密秘钥进行加密传输，因此会发送该报文。
在后续的连续发送过程中，服务端都可以采用该报文通知客户端，后续将采用新秘钥进行数据加密通信。
14 Encrypted handshake Message （S->C）
该报文的目的就是，服务端告诉客户端，自己在整个握手过程中收到了什么数据，发送了什么数据。来保证中间没人篡改报文。
该数据采用刚才协商好的秘钥进行加密，顺带验证秘钥。
15 Application Data
后续采用加密方式进行数据通信。
分手包：
https://blog.csdn.net/qq78442761/article/details/120716143