可信网站验证 可信身份认证系统( 二 )


前边说到用公钥进行加密,只有拥有私钥的人才能解密 。数字证书有点反过来:用私钥进行加密,用公钥进行解密 。CA用自己的私钥对Bob的信息(包含Bob公钥)进行加密,由于Alice无条件信任CA,所以已经提前知道CA的公钥,当她收到Bob证书的时候,只要用CA的公钥对Bob证书内容进行解密,发现能否成功解开(还需要校验完整性),此时说明Bob就是Bob,那之后用证书里边的Bob公钥来走之前的流程,就解决了中间人欺骗这个问题了 。这种方式也是一种防抵赖的方式,让对方把消息做一个数字签名,只要我收到消息,用对方的公钥成功解开校验这个签名,说明这个消息必然是对方发给我的,对方不可以抵赖这个行为,因为只有他才拥有做数字签名的私钥 。
CA其实是有多级关系,顶层有个根CA,只要他信任B,B信任C,C信任D,那我们基本就可以认为D是可信的 。
完整性 上边基本上已经解决了保密性和认证,还有一个完整性没有保障 。虽然Hacker还是看不懂内容,但是Hacker可以随便篡改通信内容的几个bit位,此时Bob解密看到的可能是很乱的内容,但是他也不知道这个毕竟是Alice真实发的内容,还是被别人偷偷改了的内容 。
单向Hash函数可以把输入变成一个定长的输出串,其特点就是无法从这个输出还原回输入内容,并且不同的输入几乎不可能产生相同的输出,即便你要特意去找也非常难找到这样的输入(抗碰撞性),因此Alice只要将明文内容做一个Hash运算得到一个Hash值,并一起加密传递过去给Bob 。Hacker即便篡改了内容,Bob解密之后发现拿到的内容以及对应计算出来的Hash值与传递过来的不一致,说明这个包的完整性被破坏了 。
一次安全可靠的通信 总结一下,安全可靠的保障:
对称加密以及非对称加密来解决:保密性
数字签名:认证、不可抵赖
单向Hash算法:完整性
来一张完整的图:
https握手总结:
1. 客户端发起HTTPS哀求
2. 服务端的配置
采用HTTPS协议的服务器必须要有一套数字证书,可以是自己制作或者CA证书 。区别就是自己颁发的证书需要客户端验证通过,才可以继承访问,而使用CA证书则不会弹出提示页面 。这套证书其实就是一对公钥和私钥 。公钥给别人加密使用,私钥给自己解密使用 。
3. 传送证书
这个证书其实就是公钥,只是包含了很多信息,如证书的颁发机构,过期时间等 。
4. 客户端解析证书
这部分工作是有客户端的TLS来完成的,首先会验证公钥是否有效,比如颁发机构,过期时间等,假如发现异常,则会弹出一个警告框,提示证书存在问题 。假如证书没有问题,那么就生成一个随即值,然后用证书对该随机值进行加密 。
5. 传送加密信息
这部分传送的是用证书加密后的随机值,目的就是让服务端得到这个随机值,以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了 。
6. 服务段解密信息
服务端用私钥解密后,得到了客户端传过来的随机值(私钥),然后把内容通过该值进行对称加密 。所谓对称加密就是,将信息和私钥通过某种算法混合在一起,这样除非知道私钥,不然无法获取内容,而正好客户端和服务端都知道这个私钥,所以只要加密算法够彪悍,私钥够复杂,数据就够安全 。
7. 传输加密后的信息
这部分信息是服务段用私钥加密后的信息,可以在客户端被还原 。
8. 客户端解密信息
Powered byAd.Plus
客户端用之前生成的私钥解密服务段传过来的信息,于是获取了解密后的内容 。