文章目录
1.前置知识
在了解https之前，我们需要知道一些概念。
数据指纹：我们简单的将其理解为我们发送的数据的摘要，然后通过特定的哈希算法生成的一个哈希值。它具有唯一性。
数据签名：数据指纹经过加密后边就形成了数据签名。
对称加密：我们可以将其理解为一篇密文， 需要密钥才能解开。
非对称加密：这里也是将其理解为一篇密文，但这里一对密钥，分为公钥和私钥，用公钥加密的密文只能用私钥解开，用私钥加密的密文只能用公钥解开，私钥一般是个人持有，公钥一般是发布出去的。
我们在用http传输数据的时候，通常都是明文传输，这就伴随着我们发送的内容可能会被人截取到，这时候如果有一些不怀好意的人想要获取我们的数据，就很有可能会获取到，造成信息的泄露，所以就有了https的出现。下面我们一个个的思考解决方案。
2.只使用对称加密
如果我们的服务端和客户端都使用对称加密，用密钥加密的内容发送给对方，对方再用密钥来解密，这样子是否可以呢？
我们这样子一看，我们用密钥加密的内容传输，即使中间有人截到了我们的内容，是不是也无法解密。
但是，这里有个问题：我们的密钥是不是也要被对方拿到才行？
那么如果我们在交换密钥的过程中，密钥肯定是一个裸露的状态呀。那如果这时候中间人就把密钥劫持到了呢？
这时候假如你要发的信息，中间人只要将拿到的密钥一解，不就可以知道你的信息了吗？
所以这种方案是不可以的。
———————————————————————————————
3.只使用非对称加密
既然你的对称加密对方会拿到密钥，那我换成非对称加密，在开始的时候，将公钥发给客户端，客户端再用公钥加密发给服务端。
因为私钥加密只能公钥解开，公钥加密只能私钥解开
从客户端发送信息到服务端是安全的，因为只有服务端的私钥才能解开
但是从服务端发送信息给客户端是不是不安全？因为公钥可能也会被中间人拿到，那样子的话中间人就能拿到信息了。
那现在的问题就是服务端到客户端不安全，那么我们是否可以在客户端也像服务端那样子呢？
4.双方都是使用非对称加密
- 首先我们先交换双方的公钥
- 然后由于只有对方自己才有私钥，也就是说用对方的公钥加密的内容只有对方自己的私钥才能解开。
但是非对称加密会有一个缺点，就是通信效率会变慢，但是这样子真的就安全了吗？
首先，客户端和服务端不知道对方收到的公钥是不是对方的呀！！！
那么中间人就可以抓住这个特点，
- 在交换公钥期间，把服务器要发送的公钥换成自己的发送给客户端
- 客户端要发送给服务端的公钥，中间人就把这个公钥劫持，换成自己的公钥发给对方
- 这样子是不是就完美的扮演了一个中间人拿到信息了。
5.非对称加密 + 对称加密
由于双方都使用非对称加密效率太慢了，我们只需要让对方安全的拿到对称密钥就可以了，那么我们可以这样子：让服务端使用非对称加密，客户端使用对称加密
- 客户端申请通信
- 服务端发送公钥
- 客户端将公钥加密对称密钥发给服务端
- 往后都使用公钥通信
但是这里也还是存在着一个问题，就是不知道发来的公钥是不是服务端的！
如果中间人像上一个方案那样子，将自己的公钥发过去，客服端也不知道
6.非对称加密+对称加密+CA认证
（一）CA认证
我们归根结底的问题就是不知道公钥是不是对方的，所以我们就引入证书。
CA认证：服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端公钥的权威性。
CA认证的流程：
当服务端申请CA证书的时候，CA机构会对该服务端进⾏审核，并专⻔为该⽹站形成数字签名，过程如
下：
- CA机构拥有⾮对称加密的私钥A和公钥A’
- CA机构对服务端申请的证书明⽂数据进⾏hash，形成数据摘要
- 然后对数据摘要⽤CA私钥A’加密，得到数字签名S 服务端申请的证书明⽂和数字签名S 共同组成了数字证书，这样⼀份数字证书就可以颁发给服务端了
而我们很多的浏览器和设备在出厂时就内置了CA的公钥，是可以解开查看证书内容的
（二）https
我们来看看接下来的几个问题：
（1）如果中间人像之前的方案那样子伪造假的证书发给对方呢？
这一点我们这时候就不用担心了，因为即使你中间人解开了证书，想伪造一份假证书，证书加密需要我们的私钥才能进行加密，而私钥世界上只有CA机构才有，所以中间人是造不出来假证书的。
（2）如果中间人发的就是申请的自己的证书呢？
我们也不用太担心，因为我们可以看到证书内容里包含了很多的信息，如果中间人申请了证书，域名肯定是不一样的，况且证书里面还包含了申请者的信息，那么即使追究，也能找到是谁。
像这种中间人攻击的方式，我们将其称为 “MTM攻击”。
版权归原作者 代码探险家（小符） 所有， 如有侵权，请联系我们删除。