【HTTPS】深入解析 https

https://i-blog.csdnimg.cn/direct/69c3d3a065ab4e2fa9c8689519b2a536.gif" width="755" />

我的主页：2的n次方_

https://i-blog.csdnimg.cn/direct/2886255420c4429bb4c6fb9fdcc510a4.gif" width="539" />

在这里插入图片描述 https://i-blog.csdnimg.cn/blog_migrate/e078a8a4deddcc408f4a37feb60eec1d.gif#pic_center" />

1. 背景介绍

在使用 http 协议的时候是不安全的，可能会出现运营商劫持等安全问题，运营商通过劫持 http 流量，篡改返回的网页内容，例如广告业务，可能会通过 Referer 字段 来统计是从哪个页面转接进来的，但是运营商就可能把信息改为自己的，也就是从运营商点击的广告，从而侵害原厂商的的利益，出了这个案例，还可能会篡改其他的信息，使得用户在访问一些界面时强制跳转广告或者下载某个应用时，点击下载却下载了其他应用等等，这些问题都是由于 http 是明文传输的，所以就引入了 https

HTTPS 其实就是 HTTP 的安全版本， HTTPS通过加密、认证和完整性保护，确保通信内容不会被第三方窃听或篡改

先来介绍几个概念：

明文：要传输的原始数据

密文：把明文进行加密之后的数据

密钥：进行加密和解密的重要数据（辅助工具）

公钥：可以公开的密钥，通常可以广泛的分发给任何需要的人

私钥：严格保密的密钥，只有密钥所有者才知道，与公钥成对出现，用于解密由客户端使用服务器公钥加密后的数据

对称加密：不论是加密还是解密，都使用同一个密钥

非对称加密：使用公钥对数据进行加密，使用私钥对数据进行解密，例如，A 要向 B 发送机密信息，A 可以使用 B 的公钥对信息进行加密，B 收到加密信息后，使用自己的私钥进行解密。

为了防止上述的数据被篡改的安全问题，就需要把数据进行加密传输

2. 引入对称加密

https://img-blog.csdnimg.cn/img_convert/f35340caa1aeb1fa5d7e42554f6bf362.png" width="911" />

一般情况下都是多个客户端对应一个服务器，这些客户端在连接上服务器之后需要自己生成一个随机的对称密钥给服务器，服务器拿到这个密钥之后才能解密，如果多个客户端使用同一个密钥，那么黑客登录一个客户端就之后密钥是什么了

但是上面的过程还是存在一个问题的：

https://img-blog.csdnimg.cn/img_convert/08e7f3c6d9279ba2b1fa3b8518985157.png" width="834" />

使用对称加密的话，这其实和不加密也没什么区别

3. 引入非对称加密

这里是在之前使用对称加密的基础上引入了非对称加密，对对称加密的密钥进行加密，那为什么不都使用非对称加密呢？非对称加密的的解密过程其实是比较消耗时间的，所以进行一次非对称加密，后续的进行对称加密既保证了数据的安全性，也保证了传输效率

客户端通过服务器的公钥对后续的对称加密的密钥进行加密，服务器通过私钥进行解密：

https://img-blog.csdnimg.cn/img_convert/2004285054ef0bb9d0750093730c72d9.png" width="1026" />

在上面的过程中，被黑客入侵的中间设备由于没有私钥，所以不能解析客户端使用公钥加密的数据，后续再进行对称加密就保证了数据的安全性

不过呢，上面的还是有缺陷的，通过中间人攻击就可以破解

4. 中间人攻击

被黑客入侵的设备在客户端面前假扮服务器，在服务器面前假扮客户端，就能够骗过双方

https://img-blog.csdnimg.cn/img_convert/c3d125bd150694b4837e3c1899fd1fa8.png" width="951" />

就像上面的过程那样，客户端并不知道当前的公钥是黑客伪造的，中间设备劫持上面的数据之后，使用自己的私钥 pri2 就知道了对称密钥的内容，信息就会被泄露篡改了

5. 证书机制

其实上面问题的关键是客户端无法区分拿到的公钥是否是正常的，通过引入证书机制就可以解决上述的中间人攻击问题，如果想要搭建服务器使用 HTTPS 就需要在公证机构里申请证书（包括证书发布机构，证书有效期，证书所有者，公钥，签名等），服务器申请到证书之后，客户端除了从服务器获取公钥之外还会获取对应的证书。

证书中的签名包括校验和 + 加密，原始数据相同，计算的校验和也就相同，校验和不同就说明被篡改过了，这里的加密采用的是非对称加密，公证机构自己也会有一对公钥和私钥，公钥分发给各种客户端，公正机构用私钥对校验和进行加密，就得到了数字签名

之后的过程就是，客户端验证数字签名

客户端吧证书中的各个字段再计算一次校验和，得到 checksum1
客户端使用公证机构的公钥对数字签名进行解密，得到 checksum2（公钥加密只有对应的私钥才能解密，私钥加密，对应的公钥才能解密）
对比两次的校验和，如果相等就表明得到的证书和服务器发过来的是同一个证书，如果不相等就意味着证书上的内容被篡改过了，就会弹出警告的信息

那么客户端怎么确定拿到的公钥是公证机构的而不是黑客篡改过的？

客户端拿到公证机构的公钥主要通过操作系统或浏览器内置的方式获得，并不是通过网络传输获得的

一般情况下黑客获得不了公证机构的私钥，如果说黑客自己去生成一个私钥，客户端的公证机构的公钥也解密不了，所以通过引入证书机制就使得传输过程更加的安全了

Fiddler 等抓包工具为什么可以解析 HTTPS 加密的数据？

抓包工具也会提供一个证书，客户端同意信任之后就能够拿到客户端的对称密钥，大概是下面的过程：

https://img-blog.csdnimg.cn/img_convert/0ab8b9ae2822f12ff455d33b11c3110f.png" width="854" />

当服务器发送的证书被 Fiddler 抓到之后，就会篡改证书中的内容，变成自己的证书，然后把整数中服务器的公钥替换成自己的公钥，根据新生成的证书重新计算得到校验和，并且使用自己的私钥来加密，得到数字签名，由于已经信任了 Fiddler 的证书，也就拿到了 Fiddler 的公钥，之后也是使用这个公钥进行加密和对称密钥的加密

在这里插入图片描述 https://i-blog.csdnimg.cn/blog_migrate/e078a8a4deddcc408f4a37feb60eec1d.gif#pic_center" />