【Linux】图解详谈HTTPS的安全传输

1.前置知识

在了解https之前，我们需要知道一些概念。

数据指纹：我们简单的将其理解为我们发送的数据的摘要，然后通过特定的哈希算法生成的一个哈希值。它具有唯一性。

数据签名：数据指纹经过加密后边就形成了数据签名。

对称加密：我们可以将其理解为一篇密文， 需要密钥才能解开。
非对称加密：这里也是将其理解为一篇密文，但这里一对密钥，分为公钥和私钥，用公钥加密的密文只能用私钥解开，用私钥加密的密文只能用公钥解开，私钥一般是个人持有，公钥一般是发布出去的。

我们在用http传输数据的时候，通常都是明文传输，这就伴随着我们发送的内容可能会被人截取到，这时候如果有一些不怀好意的人想要获取我们的数据，就很有可能会获取到，造成信息的泄露，所以就有了https的出现。下面我们一个个的思考解决方案。

2.只使用对称加密

如果我们的服务端和客户端都使用对称加密，用密钥加密的内容发送给对方，对方再用密钥来解密，这样子是否可以呢？

我们这样子一看，我们用密钥加密的内容传输，即使中间有人截到了我们的内容，是不是也无法解密。

但是，这里有个问题：我们的密钥是不是也要被对方拿到才行？
那么如果我们在交换密钥的过程中，密钥肯定是一个裸露的状态呀。那如果这时候中间人就把密钥劫持到了呢？
这时候假如你要发的信息，中间人只要将拿到的密钥一解，不就可以知道你的信息了吗？

所以这种方案是不可以的。

———————————————————————————————

3.只使用非对称加密

既然你的对称加密对方会拿到密钥，那我换成非对称加密，在开始的时候，将公钥发给客户端，客户端再用公钥加密发给服务端。

因为私钥加密只能公钥解开，公钥加密只能私钥解开

从客户端发送信息到服务端是安全的，因为只有服务端的私钥才能解开
但是从服务端发送信息给客户端是不是不安全？因为公钥可能也会被中间人拿到，那样子的话中间人就能拿到信息了。
那现在的问题就是服务端到客户端不安全，那么我们是否可以在客户端也像服务端那样子呢？

4.双方都是使用非对称加密

• 首先我们先交换双方的公钥
• 然后由于只有对方自己才有私钥，也就是说用对方的公钥加密的内容只有对方自己的私钥才能解开。

但是非对称加密会有一个缺点，就是通信效率会变慢，但是这样子真的就安全了吗？

首先，客户端和服务端不知道对方收到的公钥是不是对方的呀！！！
那么中间人就可以抓住这个特点，

• 在交换公钥期间，把服务器要发送的公钥换成自己的发送给客户端
• 客户端要发送给服务端的公钥，中间人就把这个公钥劫持，换成自己的公钥发给对方
• 这样子是不是就完美的扮演了一个中间人拿到信息了。

5.非对称加密 + 对称加密

由于双方都使用非对称加密效率太慢了，我们只需要让对方安全的拿到对称密钥就可以了，那么我们可以这样子：让服务端使用非对称加密，客户端使用对称加密

• 客户端申请通信
• 服务端发送公钥
• 客户端将公钥加密对称密钥发给服务端
• 往后都使用公钥通信

但是这里也还是存在着一个问题，就是不知道发来的公钥是不是服务端的！
如果中间人像上一个方案那样子，将自己的公钥发过去，客服端也不知道

6.非对称加密+对称加密+CA认证

（一）CA认证

我们归根结底的问题就是不知道公钥是不是对方的，所以我们就引入证书。

CA认证：服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端公钥的权威性。

CA认证的流程：

当服务端申请CA证书的时候，CA机构会对该服务端进⾏审核，并专⻔为该⽹站形成数字签名，过程如
下：

1. CA机构拥有⾮对称加密的私钥A和公钥A’
2. CA机构对服务端申请的证书明⽂数据进⾏hash，形成数据摘要
3. 然后对数据摘要⽤CA私钥A’加密，得到数字签名S
   服务端申请的证书明⽂和数字签名S 共同组成了数字证书，这样⼀份数字证书就可以颁发给服务端了

而我们很多的浏览器和设备在出厂时就内置了CA的公钥，是可以解开查看证书内容的

（二）https

我们来看看接下来的几个问题：

（1）如果中间人像之前的方案那样子伪造假的证书发给对方呢？

这一点我们这时候就不用担心了，因为即使你中间人解开了证书，想伪造一份假证书，证书加密需要我们的私钥才能进行加密，而私钥世界上只有CA机构才有，所以中间人是造不出来假证书的。

（2）如果中间人发的就是申请的自己的证书呢？

我们也不用太担心，因为我们可以看到证书内容里包含了很多的信息，如果中间人申请了证书，域名肯定是不一样的，况且证书里面还包含了申请者的信息，那么即使追究，也能找到是谁。

像这种中间人攻击的方式，我们将其称为 “MTM攻击”。