HTTPS协议的加密流程

目录

一，HTTPS是什么

二，两种加密方式

三，HTTPS的加密过程

3.1 引入对称加密

3.2 引入非对称加密

3.3 引入证书

---

一，HTTPS是什么

HTTPS也是一个应用层协议，它是在HTTP协议的基础上引入了一个加密层。因为HTTP协议的内容都是按照文本的方式明文传输的，这就导致了在传输过程中会出现被篡改的情况。

也就是说使用HTTP协议进行网络传输是不安全的，所以现在使用HTTPS协议来进一步确保用户的信息安全。

二，两种加密方式

加密就是把明文通过一系列的变换，生成密文，解密就是把密文再通过一系列的变换，还原成明文

加密的两种方式：

1）对称加密：加密和解密使用的密钥是同一个密钥

• 明文 + 密钥 => 密文
• 密文 + 密钥 => 明文。

2）非对称加密：加密和解密使用的密钥是一对密钥，分为公钥和私钥，这两者是可以互换的，使用公钥加密，就使用私钥解密，使用私钥加密，就使用公钥解密

• 明文 + 公钥 => 密文 / 明文 + 私钥 => 密文
• 密文 + 私钥 => 明文 / 密文 + 公钥 => 明文

三，HTTPS的加密过程

3.1 引入对称加密

仔细思考，上面的模型还存在一个重大问题，服务器不是只和一个客户端通信，那么这些客户端使用的密钥是相同的吗？很明显，每个客户端的密钥必须是不同的，这样彼此之间才不知道对方的密钥是啥。

既然要求每个客户端的密钥都不相同，那么就需要在每个客户端与服务器建立连接的时候，把密钥生成出来(这里涉及到一些随机数机制来确保密钥互不相同)，然后客户端再把生成出来的密钥通过网络发给服务器。

但是这里又出现了一个问题，客户端发送给服务器的密钥也是没有加密的，也就是说密钥是可以被黑客截获的，这样就又回到了最初的问题，如何加密？所以这时我们就引入了另一种加密方式 —— 非对称加密。

3.2 引入非对称加密

通过上述过程，客户端生成的密钥就不会被黑客获取到，接下来就可以通过密钥来进行通信了。这时候就会有人问了，既然可以使用非对称密钥加密，那为什么还要使用对称加密，直接全部使用非对称加密不就行了吗？

这是因为非对称加密/解密，运算成本是很高的，运算速度也比较慢，而对称加密/解密，运算成本低，速度快。所以非对称加密通常是在一些比较关键的环节使用(传递密钥)，成本就比较可控，后续传输大量的业务数据，都是使用效率更高的对称加密。这样整体的传输效率也会得到提高。

但是上述流程还存在一个漏洞，画个图理解一下：

 在上述流程中，客户端的对称密钥就会被黑客获取到，之后客户端与服务器之间的通信也就会一览无余了。那么要如何解决这种 "中间人" 问题呢？这时候就需要引入第三方公正机构。

3.3 引入证书

会发生上述 "中间人" 问题的原因是客户端无法区分这个公钥究竟是不是黑客伪造的，因此在这里就要引入第三方，即一个被大家信任的"公正机构"，如果公正机构说这个公钥是正确的，不是被伪造的，我们就可以使用这个公钥进行加密。

将这个流程画个图理解一下：

公正机构针对证书中的各个属性，计算出来的一个校验和，并对这个校验和进行加密，就得到了数字签名，这里的加密是指公正机构使用自己生成的一对非对称密钥加密，公正机构会使用自己持有的私钥对校验和进行加密，公钥会发布到各个客户端设备中（往往公钥是内置到系统中，安装了系统，就会自导公正机构的公钥）。

当客户端拿到数字签名，就可以通过系统内置的公正机构的公钥进行解密，得到最初的校验和，然后客户端在重新计算一遍校验和，看看和解密出来的校验和是否一样，如果一致，就说明证书没有被篡改，公钥是可信的。

在上述机制下，黑客就无法对证书内容进行篡改了，或者说篡改了也会被发现：

1. 如果黑客篡改了里面服务器的公钥，替换成自己的，那么客户端在进行校验和验证的时候，就会发现校验和不一致，客户端就认为公钥被篡改了
2. 如果黑客不止替换了公钥，还将数字签名给替换了，那么由于黑客没有私钥，无法对其篡改后的数据进行加密，或者说，使用自己的私钥加密后，客户端无法对其进行解密，而公正机构的公钥是客户端系统自带的，黑客无法替换
3. 如果黑客自己申请一个证书，完全替换掉服务器的证书呢？这也是行不通的，因为申请证书是需要提交材料的，其中就有网站的主域名，认证机构会对这个域名是否归你所有进行认证。

综上所述，只要通过证书的检验，就说明公钥是服务器的公钥了