TLS协商过程

一个人想着一个人 提交于 2019-11-29 19:15:34

0. 前置知识

  1. 非对称加密(比如RSA系列)算法运作机制:RSA(PrivateKey,MSG)=ENCODE,只能RSA(PublicKey,ENCODE)=MSG;RSA(PublicKey,MSG)=ENCODE,只能RSA(PrivateKey,ENCODE)=MSG
  2. RSA的难于破解基于这一数学事实:

对于两个大质数p*q =n,与N互质的数数量为(p-1)(q-1),当p或者q在1024位以上的时候要想寻找N的两个因子概率就太低了,而找到恰好的两个因子对(PublicKey,PrivateKey)就更难了。。。

1. 流程(报文及解释说明,以访问https://www.baidu.com 为例子)

1.1. ClientHello(C2S)

ClientHello

字段 解释
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个部分:

  1. 密钥交换算法:决定客户端与服务器之间在握手时如何身份验证;
  2. 批量加密算法:加密消息流,TLS完成之后使用的HTTP消息加密算法(对称加密)
  3. 消息认证码算法:创建消息摘要, 报文的信息摘要算法,也就是信息的校验码用于信息完整性校验

1.2. ServerHello(S2C)

ServerHello

字段 解释
Version TLS1.2 采用的TLS版本
Random 22c9c.... 服务端生成的随机值server_random
Cipher Suite TLS_ECDHE_RSA_WITH_CHACHA20_POLY1205_SHA256 从客户端上报的算法组中选择一个

1.3. CertAndServerExchange(S2C)

3CertAndServerExchange

服务器证书下发->Certifacate: |字段|值|解释| |---- |---- |---- | |Version|TLS1.2|采用的TLS版本| |Certificates|....|CA证书链,从根证书到服务器证书|

证书链(这里可以看到和上面的证书连是一致的):

证书链

TIP:

证书链的信任逻辑:

  1. 购买CA证书其实就是让CA机构使用自己的privateKey给你的Pubkey的做次加密生成一个签名;
  2. 基于这样一个逻辑:首先A是可信任的,那么A说B是可以信任的那么B就是可以信任的,B再说C是可以信任的那么C也是可信任的;

证书的验证大体:

  1. 读取CA证书文件的公钥签名及证书的颁发机构;
  2. 根据颁发机构获取该机构的根证书ROOTCA读取根证书(已信任)的公钥
  3. 使用根证书的公钥对签名解密出CA的实际公钥,和CA文件直接读取的进行匹配
  4. 如果匹配则继续读取其他的配置判断是否过期等等

证书基本信息(公钥,签名,使用人,颁发机构等等):

证书基本信息

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)

ServerHelloDone

1.5 ClientKeyExchange,CiperSpecHandShakeMsg(C2S)

ClientKeyExchange,CiperSpecHandShakeMsg

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协商流程简化

  1. 客户端发送一个随机数给服务端(明文),支持的算法组
  2. 服务端收到后也发送一个随机数给客户端(明文),要使用的算法,及数据签名
  3. 服务端发送证书文件(CA证书链)
  4. 客户端对证书合法性进行校验(验签名等等)
  5. 校验完成后再生成第三个随机数,第三个随机数用证书的公钥加密后发送给服务端,服务端用私钥解密得到第三个随机数。
  6. 服务端和客户端手握三个随机数然后各自生成会话密钥进行会话加密。
  7. 以后数据的机密解密就会使用会话密钥进行对称加解密了
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!