HTTPS安全通信协议原理

一、为什么需要HTTPS加密通信

二、常见的加密方式

（1）对称加密

（2）非对称加密

[（4）方案4：非对称加密 + 对称加密](#（4）方案4：非对称加密 + 对称加密)

一、为什么需要HTTPS加密通信

在互联网早期，其实大家都是用HTTP协议进行通信的，这个其实对于数据传输已经够用了，但是由于HTTP协议是直接传输明文的，即传输过程中的任何节点都能拿到该数据，如果被不法分子利用，则会造成数据泄露，财产损失等问题。

由于我们通过网络传输的任何的数据包都会经过运营商的网络设备(路由器, 交换机等),

那么运营商的网络设备就可以解析出你传输的数据内容, 并进行篡改.点击 "下载按钮", 其实就是在给服务器发送了一个 HTTP 请求, 获取到的 HTTP 响应其实就包含了该 APP 的下载链接. 运营商劫持之后, 就发现这个请求是要下载天天动听,那么就自动的把交给用户的响应给篡改成 "QQ 浏览器" 的下载地址了.

所以：因为 http 的内容是明文传输的，明文数据会经过路由器、wifi 热点、通信服务运营商、代理服务器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉，这就是中间人攻击，所以我们才需要对信息进行加密。

于是在数据安全的推动下，产生了HTTPS这一协议。HTTPS其实是基于HTTP协议的，他仅仅只是在原本的应用层和传输层中间加了一个加密层（也属于应用层的一部分），以后传递信息的时候就不是明文传递了，这样中间人只要不知道秘钥，就无法监听，篡改数据，保障了数据安全。

二、常见的加密方式

（1）对称加密

采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密，特征：加密和解密所用的密钥是相同的对称加密其实就是通过同一个 "密钥" , 把明文加密成密文, 并且也能把密文解密成明文.

特点：算法公开、计算量⼩、加密速度快、加密效率⾼

（2）非对称加密

需要两个密钥来进行加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。

非对称加密要用到两个密钥, 一个叫做 "公钥", 一个叫做 "私钥".公钥和私钥是配对的. 最大的缺点就是运算速度非常慢，比对称加密要慢很多.

特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快。

三、HTTPS的加密方案探究

既然要保证数据安全, 就需要进行 "加密".网络传输中不再直接传输明文了, 而是加密之后的 "密文".加密的方式有很多, 但是整体可以分成两大类: 对称加密和非对称加密。

（1）方案1：只使用对称加密

如果通信双方都各自持有同一个密钥 X，且没有别人知道，这两方的通信安全当然是

可以被保证的（除非密钥被破解）

引入对称加密之后, 即使数据被截获, 由于黑客不知道密钥是啥, 因此就无法进行解密,

也就不知道请求的真实内容是啥了.

但事情没这么简单. 服务器同一时刻其实是给很多客户端提供服务的. 这么多客户端, 每

个人用的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了, 黑客就也能拿到了).

因此服务器就需要维护每个客户端和每个密钥之间的关联关系, 这也是个很⿇烦的事情

比较理想的做法, 就是能在客户端和服务器建⽴连接的时候, 双方协商确定这次的密钥

是啥。所以在这种方案中，密钥具有临时性。

但是这样就产生了一个问题。如何协商本次的秘钥呢？换句话说，我们两个设定的秘钥对方怎么知道呢？还是需要网络传递，如果明文传递秘钥就相当于没有设置密钥，中间人仍然可以捕获密钥，这加密就没用了。如果使用密文传递，那么对面此时又不知道如何解开，就变成了鸡生蛋蛋生鸡的问题。

所以方案1是不合理的。

（2）方案2：只使用非对称加密

鉴于非对称加密的机制，如果服务器先把公钥以明文方式传输给浏览器，之后浏览器

向服务器传数据前都先用这个公钥加密好再传，从客户端到服务器信道似乎是安全的(有安全问题)，因为只有服务器有相应的私钥能解开公钥加密的数据。

但是服务器到浏览器的这条路怎么保障安全？

如果服务器用它的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个

公钥是一开始通过明文传输给浏览器的，若这个公钥被中间人劫持到了，那他也能用

该公钥解密服务器传来的信息了。

所以方案2也是不合理的。

（3）方案3：双方都使用非对称加密

这样看似可行，但有两方面问题：
•效率太低
•依旧有安全问题（中间人攻击）

所以方案3也是不合理的。

（4）方案4：非对称加密 + 对称加密

虽然上面已经比较接近答案了，但是依旧有安全问题

方案 2，方案 3，方案 4 都存在一个问题，如果最开始，中间人就已经开始攻击了呢？

可以看到，上述中最大的问题就是，在中间人自己生成了一套非对称密钥，假装他就是服务器的，传递给客户端，客户端并不知道啊，直接就把自己的对称秘钥传给服务器，然后中间人把这个加密文件打开一看，你客户端的对称秘钥是123456789，以后就都能用该秘钥全程监听，甚至篡改信息了。

（5）方案5：引入签名

在了解签名之前，我们先要了解一下数据指纹。

即数据指纹是把明文数据，经过一定的哈希算法，生成一个固定长度的字符串。

而签名则是对该字符串进行加密。

签名的形成是基于非对称加密算法的，注意，⽬前暂时和 https 没有关系，不要和

https 中的公钥私钥搞混了。

有了这个签名之后，我们再传递数据，就是一个被加密的明文信息+签名，由于签名是服务器生成的，所以即使中间人修改了正文部分，但是签名他是不可能更改的啊（因为他没有生成签名的密钥），所以客户端在拿到数据包后，首先判断一下正文hash取散列值，看是否和数据包中的签名相等，如果相等则说明没有被篡改，如果不相等则说明被中间人篡改了。