HTTPS 协议详解：对称加密、非对称加密、中间人攻击与数字证书

HTTPS = HTTP + S（SSL/TLS，专门用来加密的应用层协议）

由于在HTTP中，数据都是 “ 明文 ” 传输的，就很容易出现网络安全问题，为了解决这个问题，业界内推出了 HTTPS 协议

一. HTTPS 的加密方式

在对 HTTPS协议的加密方式进行讲解之前，我们要先理解密钥的概念

简单来说，密钥就是一套加密算法所对应的密码钥匙，只有拿到密钥才能够还原被加密的数据 

1.1 对称加密

对称加密，就是 加密和解密 用的是同一个密钥

在 HTTP 时，由于数据是直接明文传输的，那么如果数据在传输的过程中经过了一个黑客黑掉的路由器时，所传输的数据就会被黑客一览无余，也就造成了网络安全问题，大概的流程图如下所示

但在我们引入了对称加密之后，数据就会以密文的形式进行加密，那么，即使数据在传输的过程当中途径了黑客的路由器，黑客也不能直接拿到我们传输的数据，大概的流程图如下所示

这样看来，似乎黑客就拿不到我们传输的数据内容了，但是，事情真的有这么简单吗？

我们知道，密钥是 客户端和服务器在最初的通信时，由其中任意一方生成并通过网络传输给另一方 ，而且，有一个最大的问题是：该密钥在网络传输时是明文传输的！也就是说，黑客也是能拿到这个密钥的！所以，黑客也能够拿着得到的密钥来对加密的数据进行解析，从而拿到我们传输的数据

那么，如何解决 密钥 是明文传输所带来的网络安全问题呢？我们就需要对密钥也进行加密，那还是用对称加密的方式吗？如果是这样的话，我们又去生成一个对称密钥 key2 来对 key 进行加密，key 确实是可以通过密文传输了，但是 key2 也是要通过网络去明文传输的，那么，难道我们又要生成一个 key3 来对 key2 进行加密？当我们仔细想想就可以发现，无论这样套多少次，都总是有一层是需要明文传输的，也就是说，仅仅依靠对称加密是不能解决这个问题的

为了解决这个问题，HTTPS 就引入了非对称加密

1.2 非对称加密

非对称加密有两个密钥，一个公钥（公开的密钥），一个私钥（自己私有的密钥），用 公钥/私钥 进行加密的数据，只有持有对应的 私钥/公钥 才能对其进行解密。公钥和私钥并不相同，所以称作非对称加密

非对称加密传输之后用来对通信数据进行加密的密钥的流程图大概如下图所示

首先，客户端先用服务器公开的公钥对 密钥key 进行加密传输，像这样，即使在 密钥key 在传输的过程当中经过了黑客的路由器，黑客也只能拿到经过公钥加密后的数据，而又由于黑客手中并没有该公钥对应的私钥，所以并不能对这些加密后的数据进行解密，也就拿不到 密钥key 。在之后客户端和服务器之间就使用 密钥key 来加密通信，黑客由于没有 密钥key 也不能对这些加密数据进行解密，也就保障了网络安全

我们要注意的是，客户端和服务器之间并不能直接通过服务器提供的公钥和私钥进行加密通信，因为非对称加密运算速度巨慢而且还有明文长度上限，不能加密大文件，所以，HTTPS 采取了一个折中的方案：只使用服务器的 公钥/私钥 非对称加密传输 密钥key，之后客户端和服务器之间的数据传输都是用 密钥key 进行对称加密传输

在 HTTPS 引入了非对称加密了之后，那些狡猾的黑客难道就真的没办法去窃取我们的数据了吗？其实不然，那些狡猾的黑客又想出了一个办法来在非对称加密后获取到我们传输的 密钥key，这个办法就是 中间人攻击

二. HTTPS 典型安全隐患：中间人攻击

中间人攻击就是 黑客在客户端和服务器的网络通信之间安插了一个第三者，偷偷地去截留、篡改双方传输的数据，但客户端和服务器双方都意识不到中间有第三者

在 非对称加密 的前提下，黑客的网络设备也会生成一对 公钥和密钥 对服务器提供的公钥和私钥进行 调包，从而获取到 客户端和服务器之间用来进行网络通信加密的 密钥key

大概流程如下图所示

由于客户端不能确定传输过来的公钥是真是假，所以只能选择相信这份公钥是正确的并用这个公钥对密钥key进行加密传输，这时如果这份公钥是黑客伪造的 公钥pub2，那么在黑客拿到加密的数据后就可以用对应的 私钥pri2 进行解密从而拿到 密钥key。然后黑客再使用服务器的 公钥pub 对 密钥key 进行加密并传输给服务器，服务器也使用对应的 私钥pri 对加密的数据进行解密也拿到了密钥key。那么，在这之后客户端和服务器之间的通信数据都是以 密钥key 进行加密的，而由于黑客手中已经掌握了 密钥key，之后客户端和服务器之间的传输数据黑客都能解密偷看、篡改，而客户端和服务器双方完全无感知，这也就是中间人攻击

为了解决中间人攻击，HTTPS 又引入了校验机制 —— 数字证书

三.抵御中间人攻击的方式：数字证书

中间人攻击的关键在于客户端无法区分收到的公钥是否是服务器真实传输过来的公钥还是被黑客篡改过的公钥，想要解决中间人攻击的问题，HTTPS 就要想办法去对公钥进行校验，去判断这是否是服务器真实传输过来的公钥，而这个校验机制就是数字证书

数字证书就相当于网站的官方身份证，由公认权威机构（CA）颁发

这时，服务器就要先向 公证权威机构（CA）去申请一个数字证书，证书内包含有以下内容：证书的颁布机构、证书的有效期、服务器的公钥、服务器的拥有者（域名）和 证书的数字签名（本质上是一个被加密的校验和）

校验和就是用要校验的数据代入一个校验和的计算算法所算出的一个数字，用来快速验证数据在传输的过程当中是否被修改或出错

这时，当客户端向服务器发起通信时，就会先获取到服务器传输过来的证书并对该证书进行校验，校验无误之后才使用证书里带有的 公钥 对 密钥key 进行加密并传输给服务器，之后客户端和服务器之间的网络通信就都用 密钥key 进行加密

传输证书的流程如下图所示

客户端对证书的校验过程：

1.客户端针对证书中的其他字段（除了数字签名）使用 公证权威机构 同样的算法计算校验和，得到校验和1

2.客户端再通过公正权威机构的 公钥pub 对数字签名进行解密，得到校验和2（公正权威机构的公钥不是通过网络进行传输的，而是操作系统中内置的，黑客并不能伪造这份公钥）

3.客户端对比 校验和1 和 校验和2 是否相同，如果相同，就说明证书是没有被修改过的，也就说明整数中含有的服务器的公钥是正确的；如果不相同，那么这个证书就是中间被其他人篡改过的，属于无效证书

引入了证书之后，黑客就对我们加密的 密钥key 无能为力了

如果黑客想要直接修改证书中的公钥 为自己的公钥，就会导致客户端计算出来的 校验和1 和 解密出来的 校验和2 对不上，此时客户端就会直接报错

就算黑客想要直接替换整份服务器的证书为自己申请的证书，那也是不行的，因为证书当中包含有服务器的域名，黑客申请下来的证书中的域名和服务器的域名肯定是不同的，客户端这里还会验证 输入的 URL 中的域名 和 得到的证书中的域名是否一致，如果不一致，那么也同样会认为该证书非法，直接报错

三. 小结

HTTPS 并不是一种全新的协议，而是 HTTP 加上 SSL/TLS 加密层后的产物。它的安全机制可以概括为一句话：用非对称加密安全地传递对称密钥，再用对称密钥加密实际传输的数据。

但仅有加密还不够，因为中间人攻击可以调包公钥。为了解决这个问题，HTTPS 引入了数字证书：由权威 CA 机构颁发，证书中包含服务器公钥、域名和数字签名。客户端通过校验数字签名和域名，就能确认公钥是否真的属于目标服务器，从而抵御中间人攻击。

至此，HTTPS 通过“对称加密 + 非对称加密 + 数字证书”三件套，实现了数据传输的机密性、完整性和身份认证。在下一篇博客，我们将进入传输层，看看 TCP 和 UDP 是如何工作的