让各大运营商都默默流泪的 HTTPS 协议(HTTPS 的加密流程)

本文主要是介绍让各大运营商都默默流泪的 HTTPS 协议(HTTPS 的加密流程)，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

---

前言

在之前的文章中我们介绍了 HTTP 协议, 随着互联网的不断发展, 有越来越多的 “坏人”, 钻网络的漏洞来牟利.

HTTP虽然使用极为广泛, 但是却存在不小的安全缺陷, 主要是其数据的明文传送和消息完整性检测的缺乏, 而这两点恰好是网络支付, 网络交易等新兴应用中安全方面最需要关注的.

HTTPS 是在 HTTP 的基础上加入了 SSL, 可以简单将它理解成 HTTP 协议的安全版(不谈细节). 所以我们讲过的 HTTP 相关的知识, 在 HTTPS 中同样有效.

还不知道 HTTP 协议? 来看这篇 HTTP协议

关注收藏, 开始学习吧🧐

---

1. 什么是 HTTPS

HTTPS (Hypertext Transfer Protocol Secure), 是以安全为目标的 HTTP 通道, 在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性.

HTTP 协议内容都是按照文本的方式明文传输的. 这就导致在传输过程中出现一些被篡改的情况.

HTTPS 也是一个应用层协议.

1.1 臭名昭著的 “运营商劫持”

几年前在浏览器页面上尝试下载一个 天天动听.

未被劫持的效果, 点击下载按钮, 就会弹出天天动听的下载链接.

被运营商劫持后, 点击下载按钮, 就会弹出 QQ 浏览器的下载链接.

由于我们通过网络传输的任何的数据包都会经过运营商的网络设备(路由器, 交换机等), 那么运营商的网络设备就可以解析出你传输的数据内容, 并进行篡改.

点击 “下载按钮”, 其实就是在给服务器发送了一个 HTTP 请求, 获取到的 HTTP 响应其实就包含了该 APP 的下载链接. 运营商劫持之后, 就发现这个请求是要下载天天动听, 那么就自动的把交给用户的响应给篡改成 “QQ浏览器” 的下载地址了.

那么运营商劫持的目的是什么呢?

当然是为了钱了, 每一次下载点击都可以给运营商提供盈利, 所以就会有了这种偷偷摸摸的事儿.

不止运营商可以劫持, 其他的网络黑客也可以用类似的手段进行劫持, 来窃取用户隐私信息, 或者篡改内容.

试想一下, 如果黑客在用户登陆支付宝的时候获取到用户账户余额, 甚至获取到用户的支付密码…后果将会是怎样的.

所以随着时代的发展, 人们意识到了安全的重要性. 也发现了在互联网上, 明文传输是比较危险的事情. 于是便有了 HTTPS, 在 HTTP 的基础上进行了加密, 进一步的来保证用户的信息安全.

2. 什么是"加密"

加密解密发展到如今, 计算机中, 有一个专门的分支学科, 叫做 “密码学”. 其本质上是从数学学科延伸过来的, 有很多数学上的知识. 其中就有对 “加密”, “解密” 等一系列操作的解释.

数据加密是一种将数据从明文（未加密）转换为密文（加密）的方法。 用户可以使用加密密钥访问加密数据，使用解密密钥访问解密数据。

• “加密” 就是把 “明文” (要传输的信息)进行一系列变换, 生成 “密文” .
• “解密” 就是把 “密文” 再进行一系列变换, 还原成 “明文” .

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

3. HTTPS 的加密流程

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

3.1 对称加密

对称加密的加密流程, 简单说就是有一个密钥, 它可以加密一段信息, 也可以对加密后的信息进行解密, 和我们日常生活中用的钥匙作用差不多.

这把钥匙能把明文加密成密文, 也能把密文解密成明文.

每个客户端都需要有一把自己的对称密钥(不同客户端的密钥也要不同), 客户端生成了密钥, 需要把密钥传输给服务器, 让服务器知道这次通信的密钥是什么.

引入对称加密之后, 即使数据被截获, 由于黑客不知道密钥是啥, 因此就无法进行解密, 也就不知道请求的真实内容是啥了.

用对称加密可行吗？

如果通信双方都各自持有同一个密钥，且没有别人知道，这两方的通信安全当然是可以被保证的（除非密钥被破解）。

然而最大的问题就是这个密钥怎么让传输的双方知晓，同时不被别人知道。前面讲到由服务器生成一个密钥并传输给浏览器，那在这个传输过程中密钥被别人劫持到手了怎么办？之后他就能用密钥解开双方传输的任何内容了，所以这么做是当然不行的。

而浏览器也不可能做到预存好世界上所有HTTPS网站的密钥。现在怎么办？当下我们就需要使用非对称加密了。

3.2 引入非对称加密

简单来说非对称加密，就是有两把密钥，通常一把叫做公钥、一把叫私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。

公钥和私钥是配对的, 最大的缺点就是运算速度非常慢, 比对称加密要慢很多.

• 通过公钥对明文加密, 变成密文
• 通过私钥对密文解密, 变成明文

也可以反着用

• 通过私钥对明文加密, 变成密文
• 通过公钥对密文解密, 变成明文

• 客户端在本地生成对称密钥, 通过公钥加密, 发送给服务器.
• 由于中间的网络设备没有私钥, 即使截获了数据, 也无法还原出内部的原文, 也就无法获取到对称密钥.
• 服务器通过私钥解密, 还原出客户端发送的对称密钥. 并且使用这个对称密钥加密给客户端返回的响应数据.
• 后续客户端和服务器的通信都只用对称加密即可. 由于该密钥只有客户端和服务器两个主机知道, 其他主机/设备不知道密钥即使截获数据也没有意义.

用对称加密+非对称加密可行吗？

上述我们使用非对称加密+对称加密的方法传输数据, HTTPS 基本就是采用了这种方案, 耗时的非对称加密解密操作只需要进行一次, 后续客户端和服务器通信都只用对称加密即可.

这样的方案看似完美, 实际上还是有空子可以钻.

3.3 中间人攻击

再来简单看一下我们当前的方案:

1. 某网站拥有用于非对称加密的公钥A、私钥A。
2. 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
3. 浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
4. 服务器拿到后用私钥A’解密得到密钥X。
5. 这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都通过密钥X加密解密即可。

此时有一个 “中间人” 来捣乱, 如果在数据传输过程中，中间人劫持到了数据，此时他的确无法得到浏览器生成的密钥X，这个密钥本身被公钥A加密了，只有服务器才有私钥A’解开它，然而中间人却完全不需要拿到私钥A’就能干坏事了。请看下面操作：

1. 某网站有用于非对称加密的 公钥A、私钥A。
2. 浏览器向网站服务器请求，服务器把 公钥A 明文给传输浏览器。
3. 中间人劫持到 公钥A，保存下来，把数据包中的 公钥A 替换成自己伪造的 公钥B（它当然也拥有 公钥B 对应的 私钥B）。
4. 浏览器生成一个用于对称加密的密钥X，用 公钥B（浏览器无法得知公钥被替换了）加密后传给服务器。
5. 中间人劫持后用 私钥B 解密得到 密钥X，再用 公钥A 加密后传给服务器。
6. 服务器拿到后用 私钥A 解密得到 密钥X。

中间人一套 “狸猫换太子” 的操作，掉包了服务器传来的公钥，进而得到了密钥X。后续就可以肆无忌惮的干坏事儿了。根本原因是浏览器无法确认收到的公钥是不是网站自己的。

如何证明浏览器收到的公钥一定是该网站的公钥？

现实生活中，是如何证明某身份证号一定是小明的，可以看他的身份证，而身份证是由政府作证的，上面就有小明的身份证号，可以进行对比。

那能不能类似地有个机构充当互联网世界的“身份证”呢？让它作为一切证明的源头。

它就是CA机构，它是如今互联网世界正常运作的前提，而CA机构颁发的“身份证”就是数字证书。

3.4 数字证书

网站在使用 HTTPS 前，需要向CA机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明“该公钥对应该网站”。

在客户端和服务器刚一建立连接的时候, 服务器给客户端返回一个 证书. 这个证书包含了刚才的公钥, 也包含了网站的身份信息.

当客户端获取到这个证书之后, 会对证书进行校验(防止证书是伪造的).

• 判定证书的有效期是否过期
• 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
• 验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到一个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对比 hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的.

如何防止数字证书被篡改？

我们把证书原本的内容生成一份“签名”，比对证书内容和签名是否一致就能判别是否被篡改。这就是数字证书的“防伪技术”，这里的“签名”就叫数字签名.

数字签名的制作过程：

• CA机构拥有非对称加密的私钥和公钥。
• CA机构对证书明文数据T进行hash。
• 对hash后的值用私钥加密，得到数字签名S。

明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了。那浏览器拿到服务器传来的数字证书后，如何验证它是不是真的？（有没有被篡改、掉包）

浏览器验证过程：

• 拿到证书，得到明文T，签名S。
• 用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥），得到S’。
• 用证书里指明的hash算法对明文T进行hash得到T’。

显然通过以上步骤，T’应当等于S‘，除非明文或签名被篡改。所以此时比较S’是否等于T’，等于则表明证书可信。

总结

HTTPS 工作过程中涉及到的密钥有三组.

• 第一组(非对称加密): 用于校验证书是否被篡改. 服务器持有私钥(私钥在注册证书时获得), 客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器使用这个私钥对证书的签名进行加密. 客户端通过这个公钥解密获取到证书的签名, 从而校验证书内容是否是篡改过.
• 第二组(非对称加密): 用于协商生成对称加密的密钥. 服务器生成这组 私钥-公钥 对, 然后通过证书把公钥传递给客户端. 然后客户端用这个公钥给生成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥.
• 第三组(对称加密): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密.

其实一切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥工作的.

第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器.
第一组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥

---

总结

✨ 本文主要讲解了 HTTPS 协议的加密解密流程. 谈到了对称加密, 非对称加密方法, 以及HTTPS 最终使用的方法, 还谈到了数字证书的知识.
✨ 想了解更多计算机网络的知识, 可以收藏一下本人的计算机网络学习专栏, 里面会持续更新本人的学习记录, 跟随我一起不断学习.
✨ 感谢你们的耐心阅读, 博主本人也是一名学生, 也还有需要很多学习的东西. 写这篇文章是以本人所学内容为基础, 日后也会不断更新自己的学习记录, 我们一起努力进步, 变得优秀, 小小菜鸟, 也能有大大梦想, 关注我, 一起学习.

再次感谢你们的阅读, 你们的鼓励是我创作的最大动力!!!!!

这篇关于让各大运营商都默默流泪的 HTTPS 协议(HTTPS 的加密流程)的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---