文章目录
1.前置知识
在了解https之前,我们需要知道一些概念。
我们在用http传输数据的时候,通常都是明文传输,这就伴随着我们发送的内容可能会被人截取到,这时候如果有一些不怀好意的人想要获取我们的数据,就很有可能会获取到,造成信息的泄露,所以就有了https的出现。下面我们一个个的思考解决方案。
2.只使用对称加密
如果我们的服务端和客户端都使用对称加密,用密钥加密的内容发送给对方,对方再用密钥来解密,这样子是否可以呢?
我们这样子一看,我们用密钥加密的内容传输,即使中间有人截到了我们的内容,是不是也无法解密。
但是,这里有个问题:我们的密钥是不是也要被对方拿到才行?
那么如果我们在交换密钥的过程中,密钥肯定是一个裸露的状态呀。那如果这时候中间人就把密钥劫持到了呢?
这时候假如你要发的信息,中间人只要将拿到的密钥一解,不就可以知道你的信息了吗?
所以这种方案是不可以的。
———————————————————————————————
3.只使用非对称加密
既然你的对称加密对方会拿到密钥,那我换成非对称加密,在开始的时候,将公钥发给客户端,客户端再用公钥加密发给服务端。
因为私钥加密只能公钥解开,公钥加密只能私钥解开
从客户端发送信息到服务端是安全的,因为只有服务端的私钥才能解开
但是从服务端发送信息给客户端是不是不安全?因为公钥可能也会被中间人拿到,那样子的话中间人就能拿到信息了。
那现在的问题就是服务端到客户端不安全,那么我们是否可以在客户端也像服务端那样子呢?
4.双方都是使用非对称加密
- 首先我们先交换双方的公钥
- 然后由于只有对方自己才有私钥,也就是说用对方的公钥加密的内容只有对方自己的私钥才能解开。
但是非对称加密会有一个缺点,就是通信效率会变慢,但是这样子真的就安全了吗?
首先,客户端和服务端不知道对方收到的公钥是不是对方的呀!!!
那么中间人就可以抓住这个特点,
- 在交换公钥期间,把服务器要发送的公钥换成自己的发送给客户端
- 客户端要发送给服务端的公钥,中间人就把这个公钥劫持,换成自己的公钥发给对方
- 这样子是不是就完美的扮演了一个中间人拿到信息了。
5.非对称加密 + 对称加密
由于双方都使用非对称加密效率太慢了,我们只需要让对方安全的拿到对称密钥就可以了,那么我们可以这样子:让服务端使用非对称加密,客户端使用对称加密
- 客户端申请通信
- 服务端发送公钥
- 客户端将公钥加密对称密钥发给服务端
- 往后都使用公钥通信
但是这里也还是存在着一个问题,就是不知道发来的公钥是不是服务端的!
如果中间人像上一个方案那样子,将自己的公钥发过去,客服端也不知道
6.非对称加密+对称加密+CA认证
(一)CA认证
我们归根结底的问题就是不知道公钥是不是对方的,所以我们就引入证书。
- CA机构拥有⾮对称加密的私钥A和公钥A’
- CA机构对服务端申请的证书明⽂数据进⾏hash,形成数据摘要
- 然后对数据摘要⽤CA私钥A’加密,得到数字签名S
服务端申请的证书明⽂和数字签名S 共同组成了数字证书,这样⼀份数字证书就可以颁发给服务端了
而我们很多的浏览器和设备在出厂时就内置了CA的公钥,是可以解开查看证书内容的
(二)https
我们来看看接下来的几个问题:
(1)如果中间人像之前的方案那样子伪造假的证书发给对方呢?
这一点我们这时候就不用担心了,因为即使你中间人解开了证书,想伪造一份假证书,证书加密需要我们的私钥才能进行加密,而私钥世界上只有CA机构才有,所以中间人是造不出来假证书的。
(2)如果中间人发的就是申请的自己的证书呢?
我们也不用太担心,因为我们可以看到证书内容里包含了很多的信息,如果中间人申请了证书,域名肯定是不一样的,况且证书里面还包含了申请者的信息,那么即使追究,也能找到是谁。
像这种中间人攻击的方式,我们将其称为 “MTM攻击”。