这篇文章主要介绍“TLS协商过程是怎样的”，在日常操作中，相信很多人在TLS协商过程是怎样的问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”TLS协商过程是怎样的”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
0. 前置知识
非对称加密（比如RSA系列）算法运作机制：RSA(PrivateKey,MSG)=ENCODE,只能RSA(PublicKey，ENCODE)=MSG;RSA(PublicKey,MSG)=ENCODE,只能RSA(PrivateKey,ENCODE)=MSG
RSA的难于破解基于这一数学事实:
对于两个大质数p*q =n,与N互质的数数量为(p-1)(q-1),当p或者q在1024位以上的时候要想寻找N的两个因子概率就太低了，而找到恰好的两个因子对（PublicKey,PrivateKey）就更难了。。。
1. 流程(报文及解释说明，以访问https://www.baidu.com 为例子)
1.1. ClientHello（C2S）
| 字段 | 值 | 解释 |
|---|
| Version | TLS1.0 | 采用的TLS版本 |
| Random | 0acc.... | 客户端生成的随机值client_random |
| Cipher Suites | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | 客户端支持的加解密算法组合列表，分为3个部分密钥交换算法(ECDHE_RSA)，批量加密算法(AES_128_GCM)，消息认证码算法(SHA256) |
TIP: Cipher Suite 分为3个部分：
密钥交换算法:决定客户端与服务器之间在握手时如何身份验证;
批量加密算法：加密消息流，TLS完成之后使用的HTTP消息加密算法(对称加密)
消息认证码算法：创建消息摘要, 报文的信息摘要算法，也就是信息的校验码用于信息完整性校验
1.2. ServerHello(S2C)
| 字段 | 值 | 解释 |
|---|
| Version | TLS1.2 | 采用的TLS版本 |
| Random | 22c9c.... | 服务端生成的随机值server_random |
| Cipher Suite | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1205_SHA256 | 从客户端上报的算法组中选择一个 |
1.3. CertAndServerExchange(S2C)
服务器证书下发->Certifacate:
| 字段 | 值 | 解释 |
|---|
| Version | TLS1.2 | 采用的TLS版本 |
| Certificates | .... | CA证书链，从根证书到服务器证书 |
证书链(这里可以看到和上面的证书连是一致的)：
TIP:
证书链的信任逻辑：
购买CA证书其实就是让CA机构使用自己的privateKey给你的Pubkey的做次加密生成一个签名；
基于这样一个逻辑：首先A是可信任的，那么A说B是可以信任的那么B就是可以信任的，B再说C是可以信任的那么C也是可信任的；
证书的验证大体：
读取CA证书文件的公钥签名及证书的颁发机构；
根据颁发机构获取该机构的根证书ROOTCA读取根证书（已信任）的公钥
使用根证书的公钥对签名解密出CA的实际公钥，和CA文件直接读取的进行匹配
如果匹配则继续读取其他的配置判断是否过期等等
证书基本信息(公钥,签名，使用人,颁发机构等等)：
ServerKeyExchange:
| 字段 | 值 | 解释 |
|---|
| Version | TLS1.2 | 采用的TLS版本 |
| Pubkey | 22c9c.... | Diffie-Hellman生成的安全数x 使用函数（p,g,pubKey=g^x mod p）计算pubkey后发送给Client,pubkey是使用ECDHE_RSA算法加密的，客户端需要用同样的算法和Certificate的公钥进行进行解密 |
| Signature* | .... | 本段报文的签名算法及签名 |
1.4 ServerHelloDone(S2C)
1.5 ClientKeyExchange,CiperSpecHandShakeMsg(C2S)
ClientKeyExchange:
| 字段 | 值 | 解释 |
|---|
| Pubkey | ... | Diffie-Hellman生成的安全数y，根据函数pubKey=g^y mod p 生成pubkey发送给服务端，使用ECDHE_RSA算法公钥加密后发送给服务器 |
ChangeCipherSpec: 切换信息加密算法(对称加密，在此例中为CHACHA20_POLY1205)
2.后续
2.1 生成对称加密密钥
在协商过程中生成的各种随机数会被用来生成一个会话密钥(这个算法是通用的...)；
2.2 使用对称加密来生成加密HTTP报文
后续所有请求都是基于对称加密算法(在此例中为CHACHA20_POLY1205)的密文了（不会使用效率比较低的非对称算法）
3. TLS协商流程简化
客户端发送一个随机数给服务端（明文）,支持的算法组
服务端收到后也发送一个随机数给客户端（明文），要使用的算法，及数据签名
服务端发送证书文件（CA证书链）
客户端对证书合法性进行校验（验签名等等）
校验完成后再生成第三个随机数，第三个随机数用证书的公钥加密后发送给服务端，服务端用私钥解密得到第三个随机数（密文）。
服务端和客户端手握三个随机数然后各自生成会话密钥进行会话加密。
以后数据的机密解密就会使用会话密钥进行对称加解密了
4. 抓包文件
TLS-wareshark
到此，关于“TLS协商过程是怎样的”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注天达云网站，小编会继续努力为大家带来更多实用的文章！