网络原理（五）：HTTPS - 加密 & SSL 握手流程

目录

1. 什么是 HTTPS

1.1 HTTPS 的由来

2. 加密

1.2 对称加密 / 非对称加密

3. HTTPS 的工作原理(SSL 的握手过程) [面试高频考点]

3.1 引入对称加密

3.2 引入非对称加密

3.2.1 非对称加密, 加密对称密钥

3.2.2 中间人攻击

3.3 引入校验机制

3.3.1 证书

3.3.1.1 数字签名

3.3.2 客户端校验

---

1. 什么是 HTTPS

HTTPS 也是应用层的一个协议, 是在 HTTP 的基础上引入了一个加密层, 使得传输的数据更加安全.

HTTPS 出现, 只有一个目的: 安全.

HTTPS = HTTP + S (SSL / TLS) => SSL 也是一个专门用来加密的应用层协议, TLS 是它的升级版.

1.1 HTTPS 的由来

由于 HTTP 报文的 URL 中带有域名, 所以 URL 在广告行业起到一个重要作用: 广告主通过 URL 的域名来区分多个广告平台, 从而向广告平台支付广告费.

在十年前的时候(大概 2014 年左右), 由于网络法律条文还不够完善, 运营商就钻了法律的空子, 经常修改其他广告平台的 Referer(将域名改成自己的), 将广告费算到自己的头上, 以此为自己谋利益(运营商劫持).

正是因为这件事, 百度, 搜狗, 360 等大厂牵头, 将 HTTP 升级为了 HTTPS, 对 HTTP 数据报进行加密传输(Referer 也被加密了).

2. 加密

什么是加密呢?? 

我们上面提到的运营商劫持事件, 之所以运营商能够 URL 中的数据, 是因为 HTTP 报文中的数据是明文传输的, "明文" 就是指没有加密的数据, 任何人都能看得见.

而将这些 "明文" 数据升级到 "密文" 的过程, 就是加密. 并且, 明文和密文之间可以相互转化:

1. 明文加密得到密文.
2. 密文解密得到明文.

加密和解密的过程中, 一个关键的部件必不可少: 密钥. 

有了密钥, 才能对数据进行加密和解密操作. (密钥是一个很长的字符串)

1.2 对称加密 / 非对称加密

加密的形式分为以下两大类:

1. 对称加密: 加密和解密使用同一个密钥
2. 非对称加密: 加密使用一个密钥, 解密使用另一个密钥

在非对称加密中, 使用的两把密钥虽然不同, 但是存在关联关系的, 不过外人很难猜~

在非对称加密中的两把密钥, 一个称为公钥, 一个称为私钥:

1. 公钥: 公开出去的那把密钥, 所有人都能用. (用来加密, 可以当做一把锁)
2. 私钥: 自己保存的那把密钥, 不让任何人知道. (用来解密, 当做公钥的钥匙)

注意: 一个服务器是可以给多个客户端提供服务的, 所以一个服务器和不同的客户端进行通信时, 使用的密钥都是不同的.

就像你家门的钥匙, 和我家门的钥匙, 必然是不同的~~

3. HTTPS 的工作原理(SSL 的握手过程) [面试高频考点]

最开始时, 数据传输时是以 "明文" 的方式进行传输的, 既然是明文, 那么数据是很容易被黑客截获的, 极不安全.(例如, 运营商劫持)

3.1 引入对称加密

我们在明文传输的基础上, 使用对称密钥来对数据进行对称加密. 

此时, 客户端就可以对数据使用 key 来进行加密, 如果黑客不知道 key 是啥, 就不能得到里面的数据了.

客户端和服务器最开始进行通信时, 需要一方来生成对称密钥, 再通过网络传给另一方. (这里假设密钥 key 是由客户端生成的)

可是又一个问题出现了, 虽然现在黑客不知道里面的数据是啥, 但是服务器那边也不知道数据是啥了呀(因为服务器还没有拿到密钥)!!

也就是说, 我们需要先把 key 传给服务器后, 服务器才能对加密过的数据解密.

可以, 传输 key 的时候, 又成了明文传输!! 黑客能够捕获到 key 了, 那后面的操作不就形同虚设了吗??

该怎么办呢?? 难道再使用 key2 对 key 进行加密吗?? 肯定是不可行的, 因为这样 key2 又成明文的了.... 不管套多少层, 最外面的一层总是明文传输的~

所以, 仅仅使用对称加密, 是不可行的.

3.2 引入非对称加密

3.2.1 非对称加密, 加密对称密钥

非对称加密, 就是为了解决对称密钥传输的安全性问题.

这次, 由服务器端生成一个私钥和多个公钥, 其中, 私钥服务器自己保存, 公钥则传输给客户端(虽然公钥在传输的过程中可能被黑客截获, 但是无所谓, 因为本来就是公开的~)

当客户端拿到公钥后, 使用公钥对 key(对称密钥, 这里由客户端生成) 进行加密, 再将这个被加密过的对称密钥 key 传输给服务器.

注意: 此时被加密过的 key, 黑客是无法截获的, 因为黑客手上只有公钥, 而公钥只是一把锁, 只能用来加锁, 不能用来解锁. 用来解锁的私钥只在服务器手上!!

当被公钥加密后的 key 到达服务器手中后, 服务器就可以使用手中的私钥来对密文进行解密, 拿到对称密钥 key 了.

此后客户端和服务器之间就可以使用 key 来对数据进行加密传输了, 黑客便无法截获数据.

此时, 使用的是 对称加密 + 非对称加密 相结合的形式, 来保证数据传输的安全性. 

那为什么要使用 对称加密 + 非对称加密, 而不直接全部使用非对称加密呢??

1. 对称加密, 运算速度快, 开销小, 效率高, 可以对大量数据进行加密.
2. 非对称加密, 运算速度慢, 开销大, 效率低, 耗时高.

故: 使用对称加密加密业务数据; 使用非对称加密, 加密对称密钥.

现在来看, 数据似乎已经被保护起来了, 但其实, 目前的方案依然存在严重的安全隐患~~

3.2.2 中间人攻击

在上述的方案中, 黑客依然可以通过一些特殊的手段, 来获取到对称密钥, 从而窃取到后续客户端和服务器交互的数据.

这种手段称为 "中间人攻击".

上文说到, 引入非对称加密的流程是, 服务器生成一对公钥 pub1 和私钥 pri1, 私钥自己留着(解锁用), 公钥发给客户端(解锁用), 客户端收到公钥 pub1 后, 使用 pub1 对对称密钥 key 加密再传给服务器.

但是, 黑客有没有可能将服务器向客户端发送的公钥进行调包呢?? --- 肯定是有可能的.

黑客自己也会生成一对公钥 pub2 和私钥 pri2, 当服务器向客户端发送的 pub1 到达被黑客入侵的路由器后, 黑客会将服务器生成的 pub1 调换成自己生成的 pub2, 用户收到 pub2 后, 由于客户端无法区分这个 pub2 是服务器生成的, 还是被黑客篡改的, 所以就会使用 pub2 对 key 进行加密, 被 pub2 加密的 key, 也自然能被黑客使用 pri2 解密, 黑客获取到 key 后, 再将 key 使用 pub1 加密, 发送给服务器, 服务器同样也完全可以使用 pri1 解密来拿到 key, 而服务器没有意识到 key 已经被黑客获取到了, 所以后续客户端和服务器之间就会使用对称密钥 key 来进行加密传输.

所以, 黑客这个偷梁换柱的操作, 后续客户端和服务器的之间交互也就被黑客了如指掌了~

所以, 由于存在中间人修改服务器公钥的情况, 因此仅仅引入非对称加密是不够的.

3.3 引入校验机制

中间人攻击, 最主要的原因就是:

• 客户端是一个唐僧, 没有区分 pub2 是人是妖的能力, 无法区分发来的公钥是服务器初始生成的, 还是被黑客篡改过的.

所以, 要解决这个问题, 就需要客户端能够对收到的公钥进行校验, 如果判断公钥是服务器原始生成的, 就对 key 加密, 进行后续通信; 如果判断公钥是黑客篡改的, 就结束通信.

这个校验机制的关键就在于 --- 证书中的数字签名.

3.3.1 证书

服务器在搭建的时候, 就会向第三方认证机构(可信任的, 可以理解为警察局)申请一个数字证书, 申请时, 服务器需要向认证机构上传服务器域名, 生成的公钥, ... 等等一系列的材料.

认证机构就会根据服务器上传的材料向服务器颁发数字证书, 证书中包含了以下信息:

1. 证书的颁布机构
2. 证书的有效期
3. 服务器生成的公钥
4. 服务器的拥有者(域名)
5. 证书的数字签名

其中, 数字签名就是用户进行校验的关键信息.

3.3.1.1 数字签名

证书中的数字签名, 本质上是一个被加密的校验和.

校验和, 就是把所有要校验的数据带入到一个固定的公式中, 得到一个数字, 这个数字, 就是校验和.(类似于哈希函数)

所以, 校验和具有以下特点:

1. 当输入的值相同时, 得到的校验和就是相同的.
2. 当输入的值不同时, 得到的校验和大概率就是不同的.

故, 如果校验和不同, 那么输入的初始值(往公式中带入的值)就是不同的.

而,  数字签名中的校验和, 就是根据证书中的其他关键信息(包括服务器生成的公钥, 域名, ...), 经过计算得来的.

认证机构再使用自己生成的非对称密钥 pri2(仅公正机构自身持有), 对生成的校验和进行加密, 得到的就是数字签名.

数字签名的生成过程如下:

1. 把关键信息(包括服务器公钥)作为输入, 生成校验和.
2. 使用 pri2 进行加密.

3.3.2 客户端校验

服务器得到认证机构颁发的证书后, 就会向客户端发送证书(证书中有公钥和数字签名), 客户端收到证书后, 就会对数字签名进行校验操作:

1. 客户端会对证书中的其他字段, 使用相同的算法, 重新计算一遍, 得到 校验和1(这个校验和是针对用户收到的数据进行计算得到的)
2. 再使用公正机构的公钥 pub2 对数字签名解密, 得到 校验和2(这个校验和是服务器申请证书时, 得到的原始的正确的校验和)
3. 对比校验和1和校验和2是否相同.

如果 校验和1 和 校验和2 相同, 则说明证书的是没有被修改过的, 也就说明其中的公钥没有被篡改, 继续交易.(后续客户端继续使用公钥对对称密钥 key 加密, 使用 key 进行加密传输)

如果 校验和1 和 校验和2 不相同, 则说明证书被中间人篡改了, 证书无效, 结束交易.

注意:

公正机构的公钥 pub2 直接内置在客户端的操作系统中(安装好系统, 系统就内置了一系列知名公正机构的公钥), 并非是通过网络传入到达客户端的, 所以不存在 pub2 是黑客伪造的情况(盗版系统除外).

可能有的同学到这里就有疑问了, 为啥引入证书后就能保证数据安全了呢??

我把初学时常见的问题总结了一下, 如下:

• 为啥黑客不能再来一波中间人替换操作, 把证书中服务器的公钥替换成自己的呢??

答: 因为数字签名是固定的, 一旦替换了公钥, 客户端计算的校验和就会和从数字签名中解密出的校验和不一致, 客户端就会出现红色报错警告.

• 黑客能不能同时修改公钥和校验和??

答: 不能. 因为黑客是没有公正机构的私钥的, 修改后无法进行二次加密的操作. 如果使用自己的私钥来进行加密, 就会导致客户端使用公正机构的公钥解密失败, 还是会弹出红色报错警告.

• 黑客也能够看到公钥和校验和, 这没事吗??

证书的作用是为了让用户校验, 防止黑客篡改公钥. 至于黑客可以看到公钥, 无所谓, 公钥本来就是公开的. 至于黑客可以看到校验和, 无所谓, 校验和就是用来校验数据的, 没啥其他的意义.

黑客对于传输的业务数据(后续 key 加密的数据), 看不了一点~~

所以, 在引入证书和数字签名后, 才真正保障了数据的安全传输. 

---

总结, 上述的四个主要流程如下:

1. 引入对称加密
2. 引入非对称加密
3. 中间人攻击
4. 引入证书 & 数字签名

上述四个流程, 也称为 SSL 的握手流程.

"握手"(handshake), 是计算机中的专业术语, 指的是通信双方发送非业务数据时的过程.

---

END