这是一个创建于 2451 天前的主题，其中的信息可能已经有所发展或是发生改变。
第二步中，返回的证书包含两部分关键内容
- 1.颁发机构，过期时间，所有者，服务器端的公钥(p) 等信息(记为 x)
- 2.对 1 中的内容进行签名(记为 y), 然后用第三方证书的私钥对 y 进行加密得到 z
返回的就是 x + z
客户端拿到第二步返回的证书(x + z)之后，应该到第三方颁发机构那边去拿公钥，对 z 进行解密(得到 y)，然后对 x 进行 hash 得到 y', 比对 y'是否等于 y
一切都没有问题了，拿出来 x 中的公钥 p，对客户端随机生成的一个私钥(s)加密，发送给服务端，服务端用自己的私钥解密，得到客户端传来的私钥 s，以后的数据来往都是用私钥 s 对称加密
我这样理解是否有问题，我看网上很多博客都说第二步拿到证书之后，没有用第三方颁发机构的公钥解密
 |
1
linyinma 2018-03-08 10:41:55 +08:00
描述的些什么啊，技术怎么能意淫呢，TLS 包含两个协议，握手协议 /记录协议
（ 1 ）握手协议： 第一步：c->s: 报文包含： {协议版本 TLS 1.0.。，密钥交换算法 RSA/DFH..， 加密 DES..，随机数 1.....} server 收到先判断版本是否支持，根据客户端和服务端都支持算法选择一种.... 第二步：s->c: 报文包含:{服务端公钥证书（注意这是证书，证书包含签名机构，过期时间，公钥信息）， 随机数 2} client 收到应答后根据本公钥证书信息在本地 CA 证书链找签名机构的公钥证书，找到后用签名机构公钥验证返回的证书合法性， 第三步：c->s:报文包含： {随机数 3 的密文（用服务器公钥加密）} 服务端收到随机数 3 的密文，用私钥解密 HASH （随机数 1 + 随机数 2 + 随机数） 得到交换密钥（这是对称密钥，用于数据加解密，其算法由握手协商决定） 上面仅仅描述大致的细节，密钥交换算法不一致，一些细节是不一样的，但本质的一样的 |
 |
2
thomaswang OP 明白了，对称加密的秘钥，是由三个步骤中的三个随机数，共同得到的
|
|
3
thomaswang OP @linyinma 明白了，对称加密的秘钥，是由三个步骤中的三个随机数，共同得到的
|
Select Language