1.公钥和网站信息我传输给了中间CA,CA生成一把公钥和私钥
先是通过SHA256压缩信息为hash字符串(方便传输),然后对这段hash字符串+公钥进行私钥加密
这个加密之后的字符串就是数字签名
——也就是 私钥加密(SHA256(网站信息+公钥))
2.然后当网站拿回这个数字签名之后,将公钥和这个数字签名发给了用户
3.用户拿CA签名公钥进行解密,此时就获得了SHA256(公钥和网站信息), 然后用户用SHA256加密公钥和网站信息,看看这两个信息一不一样
(当黑客中间拿到数字签名,想要和原来一样修改公钥,修改完之后,那么用户用SHA256加密修改后公钥和网站信息肯定和数字签名中解密出的不同)
用户的CA签名公钥是浏览器安装的时候就写入的,谁都有这个公钥,黑客也有,黑客不就可以去解密,获得公钥和网站信息了,然而没有用啊,黑客本来就可以知道这些信息,黑客只要敢修改,我那边就肯定验证不成功,原先伪造公钥就可以实现双方通过不同的回话秘钥进行通信。但是现在你如果想让用户能够验证成功那么你就需要同步修改数字签名以及证书中公钥信息,但是了你不知道私钥,你怎么同步修改呢??
4.前面说了引入中间CA第三方是为了保证服务器传给用户的公钥是没被篡改的,但是在用户传给服务器会话秘钥的时候呢,不也是会被篡改的风险嘛,这时候也没有CA证书了,怎么搞,还是同样的方法,用户通过自己的私钥来进行签名, 传输 用户私钥加密(SHA256(会话秘钥))+ 服务器公钥加密的会话秘钥
疑问:黑客不是也能用用户公钥验签得到sha256(会话秘钥)吗??
黑客可以使用用户的公钥解开数字签名,从而得到会话密钥的哈希值。但是,这并不能帮助黑客获取到实际的会话密钥。
哈希函数是单向的,这意味着你不能从哈希值反向推导出原始数据。因此,即使黑客有了会话密钥的哈希值,他们也无法得知实际的会话密钥是什么。
5.服务器拿到之后,使用用户公钥解开数字签名,看到了sha256加密的(会话秘钥),服务器通过sha256加密(服务器私钥解密(服务器公钥加密的会话秘钥)),看看相同不,如果相同,则按照这个会话秘钥进行后续的传输,大多都是约定为对称加密传输
## 证书链
实际上用户并不是直接中间CA公钥对中间CA加密的私钥进行解密的,而是服务器传输过来的是一整个证书链,确保证书不会被黑客篡改,而用户这边只有一个根证书,下载浏览器的时候默认就安装了,当传来一整条证书链的时候,这时候你想想中间CA返回给服务器的第一个证书是什么?就是自己用私钥加密的sha256加密的服务器公钥和网站信息对吧,然后中间CA的公钥呢,其实和服务器公钥一样,是存在根CA或者上级CA的数字证书里,签名永远都是上一级的私钥加密的,证书里的公钥永远都是下一级的。
为了防止签名被更改,总不能永远循环下去,一级级证明吧?所以最后的尽头就是根证书,根证书不需要有上级来签名,自己的私钥给自己签名,那自己的公钥呢,也就是根公钥,发给所有用户,在浏览器下载的时候就在里面了。
那黑客不也是也有根公钥嘛,确实是这样,他确实也能验签,验签拿到的是SHA256加密的(网站信息+网站公钥)但是能不能在中间任何一级去伪装CA呢,假如伪装了,它自己搞了一把自己的私钥和公钥,用自己私钥加密了SHA256(网站信息+公钥),网站公钥 返回给了网站,网站之后去发送给用户信息的时候发送的是什么?这个篡改的证书还有证书到根CA的证书链,没有人给这个伪造CA签名,那么中间就能发现伪造CA的存在,那黑客再嚣张一点,它想根CA都伪造了,能不能伪造呢?根CA的私钥是给自己签名的,并不是由上一级签名的,根CA的公钥在用户手里,可以进行一步步的解签保证证书链没有被篡改,假如黑客自己伪装根CA也生成了私钥和公钥,私钥签名了下一级自己伪造的中间CA,在伪装根CA的一步步验证过程中,用户确实不会发现异常,因为解签后的,和加密的是相同的,但是在根CA的解签时,用的是浏览器安装的时候自带的根CA公钥解签根CA私钥签名的下一级CA,如果根CA被篡改了,正确根CA公钥 解签(错误私钥加密的SHA256(下一级CA公钥和信息))肯定会发现和SHA256加密的(中间CA+中间CA公钥不同),形成了闭环。