第二步中,返回的证书包含两部分关键内容
返回的就是 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 明白了,对称加密的秘钥,是由三个步骤中的三个随机数,共同得到的
|