深入理解 Https 通信加密过程
0x01 对对称加密的通俗理解1
即通信的双方都使用同一个秘钥进行加解密
0x02 对非对称加密算法的通俗理解 [ RSA ]1
2
3
4私钥 + 公钥= 密钥对
即用私钥加密的数据,只有对应的公钥才能解密,用公钥加密的数据,只有对应的私钥才能解密
其实这个很容易理解,因为通信双方的手里都有一套自己的密钥对,通信之前双方会先把自己的公钥都先发给对方
然后对方再拿着这个公钥来加密数据响应给对方,等到到了对方那里,对方再用自己的私钥进行解密,就这么简单
0x03 非对称加密所造成的速度慢的问题解决办法1
2(1) 先生成一个对称加密算法的密钥,用RSA的方式先安全的发给对方
(2) 随后就不再用RSA了,只用这个对称加密的密钥来互相通信
0x04 不过,以上方式存在明显的中间人问题:1
假设,此时在客户端和服务器之间存在一个中间人,这个中间人只需要把原本双方通信互发的公钥,换成自己的公钥,这样中间人就可以轻松解密通信双方所发送的所有数据
0x05 为解决上述中间人问题,于是后来就出现了证书,简单来讲就是找了一个大家公认的中介,来证明我就是我,你就是你的问题,防止中间被篡改:1
证书中就包括个人的基本信息和最重要的公钥
0x06 乍一眼看去,上面的方案貌似还不错,但证书在传输的过程中如果被篡改了呢,所以后来就又出现了数字签名:1
2
3
4
5
6简单来讲,就是将公钥和个人信息用一个Hash算法生成一个消息摘要
这个Hash算法有个极好的特性,只要输入数据有一点点变化,那生成的消息摘要就会有巨变,能有效防止别人篡改数据
但这还是有个问题,如果中间人直接把整个原始信息依然可以伪造消息摘要
所以就出现了CA,这时CA再用它的私钥对消息摘要加密,形成签名,并把原始信息和数据签名进行合并,即所谓的`数字证书`
这样,当别人把他的证书发过来的时候,我再用同样的Hash算法,再次生成消息摘要
然后用CA的公钥对数字签名解密,得到CA创建的消息摘要,两者一比,就知道中间有没有被人篡改了
0x07 关于CA自身的安全问题:1
2
3这些CA本身也有证书来证明自己的身份,并且CA的信用是像树一样分级的,高层的CA给底层的CA做信用背书
而操作系统／浏览器中会内置一些顶层的CA的证书,其实就相当于你自动信任了他们
这些顶层的CA证书务必得安全地放入操作系统／浏览器当中,否则就全部乱套了
0x08 当你彻底理解了上述这些基础概念之后,我们再回过头来看 https 的具体通信过程就更加简单清晰明了了:
1
2
3
4
5
6-> 客户端向服务端发送请求
-> 服务端返回数字证书
-> 客户端用自己的CA[主流的CA机构证书一般都内置在各个主流浏览器中]公钥去解密证书,如果证书有问题会提示风险
-> 如果证书没问题客户端会生成一个对称加密的随机秘钥然后再和刚刚解密的服务器端的公钥对数据进行加密,然后发送给服务器端
-> 服务器端收到以后会用自己的私钥对客户端发来的对称秘钥进行解密
-> 之后双方就拿着这个对称加密秘钥来进行正常的通信
0x09 其实即使如此,我们依然可以实施中间人,下面可能是一些经常会用到的把戏,这里先顺带提一嘴,听过就好,后续还会有大篇幅更详细说明1
2
3
4劫持网关,伪造证书[务必要弄个受信任的证书才行,否则浏览器会报警]
劫持所有要转到https的http请求,在服务器响应数据时把https全部换成http,而自己则保持着和客户端的http通信以及与服务器端的https通信
另外,还有其他各种导出目标机器中https明文密码的手段
...
