认识HTTPS以及了解HTTPS的加密过程

客官°小女子只卖身不卖艺 2024-03-26 19:58 81阅读 0赞

**目录**

简单认识HTTPS：

运营商劫持：

加密的理解：

HTTPS的工作过程：

对称加密：

非对称加密：

中间人攻击

证书

--------------------

## 简单认识HTTPS： ##

HTTPS 也是一个应用层协议。是在 HTTP 协议的基础上引入了一个加密层。加密层之前叫做SSL，现在叫TLS了，所以也叫SSL/TLS协议。

我们知道HTTP是按照文本的明文方式进行传输的，这就使得传输过程中容易出现被篡改的情况。提到这些我们就不得不说一下“运营商劫持”。

## 运营商劫持： ##

运营商劫持的事情想必各位应该都遇到过，比如你想要下载一个qq音乐，正常情况下点击下载后会直接下载qq音乐，而有些情况会出现点击下载后给你下载了一个360手机助手，这就是典型的运营商劫持事件。那为什么会出现运营商劫持？为了钱！！！我们通过网络传输的数据包会经经过运营商的网络设备（如路由器，交换机等等），那么运营商的网络设备就可以解析出你传输的数据内容, 并进行篡改。点击下载本质上就是向服务器发送一个http请求，然后从服务器获得的http响应当中包含了下载的链接，然而运营商劫持之后，就会把给你的响应中的下载链接更换为360手机助手了。

![8faa722bc3f84934bacf4d5943123dcc.png][]

当然，除了运营商之外也会有黑客利用相同的手段来窃取用户的隐私信息和篡改信息来谋取利益。我们都知道在互联网上进行明文传输是非常危险的，试想一下登录支付宝的时候被黑客获取到余额甚至密码有多可怕...

所以HTTPS就是在HTTP的基础上进行了加密，通过加密来进一步保障用户的信息安全。那么具体是怎么加密的呢？

## 加密的理解： ##

简单来说加密就是把要传输的明文，也就是要传输的信息，通过一些手段进行变换生成密文。

解密就是把加密过的密文经过一系列的变换还原成明文的过程。

在这个加密和解密的过程中 , 往往需要一个或者多个中间的数据 , 辅助进行这个过程 , 这样的数据称为**密钥** 。

举个简单的例子：比如我们经常在电视中看到的电报，当A给B发送电报的时候，为了防止电报被直接截取并破译，就会进行一个加密的操作，即使被截获了，敌人也不能在短时间内破译，但是对于AB双方来说，他们之间有一个约定，别人是不知道的，所以B得到加密的电报的时候就可以直接还原成明文了。

> 在这其中：
> 
> 密文：发送的电报
> 
> 密钥：约定
> 
> 明文：电报本身要传递的信息

## HTTPS的工作过程： ##

加密的方式有很多, 但是整体可以分成两大类: 对称加密 和 非对称加密

### 对称加密： ###

对于对称加密就是通过同一个密钥，可以把明文加密成密文，也可以把密文还原的明文。

> 举个例子：我们用按位异或充当一个密钥，假设明文a=1234,密钥key=8888,那么加密后的密文b=a^key=9834。针对b再次进行使用按位异或得到明文为1234。对于字符串来说也是同理，每个字符都可以表示成一个数字。这里只是简单举个例子，HTTPS当中并不是使用按位异或。

如图：

![e42a87cf1da246a196099c8546d91f01.png][]

在这个过程当中客户端发送的是通过密钥加密过的密文，即便黑客截取到了密文，不知道密钥也是无法解密的。尽管如此，我们需要注意的是，这是一个客户端的情况，如果是多个客户端呢？这个时候服务器就需要知道每个对应客户端的密钥是什么了，也就是说服务器需要记录每个客户端的密钥，不仅如此，也想要保证客户端和服务器之间能够传递密钥。但是只要就又会引出一些安全问题：

比如我们在在客户端和服务器建立连接的时候, 双方协商确定这次的密钥是啥。但是这样的话黑客也就可以获取到密钥了！！！

![f12a878ea8ee41bdb47385cfd577fb46.png][]

如果我们直接这样传输，黑客就轻松的获得了密钥，就变得更危险了，所以我们需要对密钥的内容也进行加密！这样的话我们就需要对密钥再加一个密钥，这就出现了一个无限循环的套娃问题，就行不通了。

所以我们可以考虑使用非对称加密！

### 非对称加密： ###

> 非对称加密要用到两个密钥 , 一个叫做 " 公钥 ", 一个叫做 " 私钥 "；
> 
> 公钥和私钥是配对的 。最大的缺点就是 **运算速度非常慢** ，比对称加密要慢很多 ；
> 
> 通过公钥对明文加密, 变成密文，通过私钥对密文解密，变成明文。
> 
> 也可以反着用：  
> 通过私钥对明文加密, 变成密文  
> 通过公钥对密文解密, 变成明文

这里举个例子：

A 要给 B 一些重要的文件, 但是 B 可能不在. 于是 A 和 B 提前做出约定:  
B 说: 我桌子上有个盒子, 然后我给你一把锁, 你把文件放盒子里用锁锁上, 然后我回头拿着钥匙来开锁取文件。在这个场景中, 这把锁就相当于公钥, 钥匙就是私钥。公钥给谁都行(不怕泄露), 但是私钥只有 B 自己持有。持有私钥的人才能解密。

对于非对称加密，服务器生成一对公钥私钥，客户端持有公钥，服务器持有私钥，此时客户端的公钥从服务器拿，黑客也会知道公钥，但是黑客不知道私钥，私钥是服务器自己的，别人没法知道。

客户端使用公钥，对对称密钥进行加密，传输给服务器，然后服务器拿着自己的私钥来解密获得对称密钥，此时客户端服务器就可以使用这个对称密钥进行后续的传输了。

![e62dad8d69a44f5e93c0f7762d3cbd4a.png][]

> 由于对称加密的效率比非对称加密高很多, 因此只是在开始阶段协商密钥的时候使用非对称加密,后续的传输仍然使用对称加密。

同时非对称密钥也不是绝对安全的，比如出现中间人攻击的情况。

### 中间人攻击 ###

中间人攻击就类似于《毒战》中孙红雷扮演的角色，属于卧底。比如客户端向服务器发出请求，询问公钥，同时黑客在中间截获，向服务器也发出请求获取到服务器生成的非对称密钥中的公钥pub1，于是黑客将公钥告诉客户端公钥是pub2（公钥是黑客生成的非对称密钥中的），之后客户端生成对称密钥key，同时使用使用pub2对对称密钥key进行加密，准备将对称密钥发送给服务器，但由于使用的是pub2加密的key，所以黑客有相应的私钥pri2，可以进行解密，同时把对称密钥通过获取到的pub1公钥发送给服务器，这样黑客就完成了信息的获取。

如图所示：

![007fdde04c3845998f95f05234d3f1a0.png][]

那么怎么知道公钥是黑客的还是服务器的？（解决中间人攻击的关键）

### 证书 ###

证书本质上是引入第三方的公证机构。

服务器（网站）在设立的时候就需要去专门的机构进行认证，申请证书，审核通过会颁发证书。同时服务器生成的公钥也包含在证书中。（类似你去公安局办个身份证，身份证包含了你的各种信息）

有证书之后，客户端向服务器请求公钥的时候，就不止是请求一个公钥了，是要把整个证书请求过来，当客户端拿到证书之后就可以对证书进行校验（看看证书是不是假的，是不是被改的，是不是无效的等等），如果发现证书无效，浏览器就会弹框报警。

![e1a4a5953bc046ae8148d53fb772cd4e.png][]

证书中的签名是一个被加密的字符串，客户端可以通过认证机构提供的公钥进行解密，解密之后得到一个hash1值，然后客户端在通过同样的方法对其他字段算一次hash值得到hash2，看看hash1（从签名中接出来的）和hash2（客户端自己算的）是不是相同，相同说明有效，否则无效。同时黑客是无法进行更改证书的，比如把公钥换了，这样hash1和hash2就对不上了，就认为是无效的。而且黑客也无法重新生成签名，因为黑客不知道认证机构的私钥。

[8faa722bc3f84934bacf4d5943123dcc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/6ccaac9002834f249d8a6a24f68ae0e6.png
[e42a87cf1da246a196099c8546d91f01.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/80d2c9f1cf094fd28ff35d2a66519d47.png
[f12a878ea8ee41bdb47385cfd577fb46.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/bdcd40c703d84c20a72ddcda87833ac2.png
[e62dad8d69a44f5e93c0f7762d3cbd4a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/585c14283adc4f0a9de5729ef3868dac.png
[007fdde04c3845998f95f05234d3f1a0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/bc9d4fd2bbb64ed28f95c1e51d7f9c4d.png
[e1a4a5953bc046ae8148d53fb772cd4e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/913267eb20214e4d97221b29e91fdacc.png