「这是我参与11月更文挑战的第1天，活动详情查看：2021最后一次更文挑战」
前言
HTTP 的内容是明文传输的。如果在传输过程中内容被劫持，就会造成信息泄露的问题。若劫持者再篡改传输内容，且未被双方察觉，就导致中间人攻击问题。所以，我们需要对传输内容进行加密。
HTTPS 应运而生，HTTPS 全称超文本传输安全协议（Hyper Text Transfer Protocol over SecureSocket Layer）, 在 HTTP 的基础上加密传输内容、验证传输内容完整性以及发送方的身份认证。简单说：HTTPS = HTTP + SSL/TLS。
HTTPS 协议除协议名称、默认端口号（HTTP默认80，HTTPS默认443）以及使用 SSL/TLS 协议外，其他都是沿用 HTTP 的内容。
如果 HTTP 相关的知识有点遗忘，可以看下往期文章 贯穿 HTTP 的发展史。
计算机网络干文一篇，得消耗点耐心 ~ 。如果细节抠的还行，点个赞、收个藏，评个论 😏。
SSL/TLS
SSL（Secure Sockets Layer）安全套接层，是 TLS 传输层安全协议（Transport Layer Security）的前身，是被应用程序用来在网络中安全通信的协议，防止电子邮件、网页、消息以及其他协议被篡改或窃听。
网络模型
TLS 的名字是传输层安全协议，极易误导我们认为 TLS 是传输层相关的协议。
为了搞清楚 TLS 是属于哪一层，我们首先得清楚不同的网络模型关于层的划分，如下图所示。
OSI 七层模型定义了每一层的功能和协议，并完成与相邻层的接口通信，详细说明了各层所提供的服务，每一层都通过接口向相邻的上层提供一套确定的服务，并且使用与之相邻的下层所提供的服务。
由于 OSI 模型过于细化，实现起来比较繁琐，所以，结合 OSI 七层模型制定了实际应用的 TCP/IP 四层模型。那为啥书本上都是 TCP/IP 五层模型，其实主要目的是更清晰地去介绍计算机网络原理知识。（来自《计算机网路》注解）
回到 TLS 上来，从 TLS 功能来分析，TLS 由记录协议、握手协议、警告协议、变更密码规范协议等几个子协议组成。
其中记录协议是在传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能。握手协议则是建立在记录协议之上，用于传输数据前的身份验证，协商加密算法、交换加密密钥等。按照 OSI 七层模型来说，记录协议的功能类似表示层，握手协议类似会话层，与记录协议在传输协议之上相违背，但可以定义 TLS 是在应用层和传输层之间。
传输加密
文章开头提到 TLS 用于传输加密，那是以什么方式进行加密的呢？我们都知道加密分为对称加密和非对称加密两种方式，那就先讲讲这两个的加密算法的概念和应用吧。
对称加密
对称加密是最快速、简单的加密方式，加密和解密用的是同样的密钥，只要保证密钥仅通信双方知晓，那就是安全的，常见的对称加密算法有 AES、DES等，密钥长度通常为 128位 或 256位。
然而，现实是残酷的，密钥通过服务端传输给浏览器端的途中极易被劫持，导致密钥泄漏。那换种想法，浏览器端预先暴力存储所有HTTPS的密钥，不经服务端传输，理论上是可行的，但实践却不现实。
所以，传输数据对称加密这条路已堵死...，那来看看非对称加密算法。
非对称加密
非对称加密算法需要两个密钥：公开密钥和私有密钥。公钥和私钥是一对，如果公钥对数据进行加密，只有对应的私钥才能解密，用私钥对数据加密，也只有对应公钥可以解开，常用的非对称加密算法有RSA、DSA，密钥长度通常为 2048位 或更高。
那么，非对称加密如何应用在 TLS 呢？
设想一下：服务端先把公钥以明文的形式传输给浏览器端，浏览器端在传输数据之前都用这个公钥去加密，这样数据就不会泄漏，因为只有服务器的私钥能解开公钥加密的数据。但不要忘记，公钥我们是以明文传输的，如果被中间人劫持，那服务端传输的数据就会暴露。
所以，仅使用非对称加密只能保证浏览器端到服务器端的安全性。
既然这样，有一种办法就是使用两对公钥和私钥。可是，非对称加密算法过于耗时，导致方案无法真正落地。
混合加密
混合加密，顾名思义，就是非对称加密+对称加密。其实就是用对称加密替换一次非对称加密，减少耗时。HTTPS 基本就采用了这种方案。
服务端将公钥以明文的方式传输给浏览器端，浏览器端生成一个用于对称加密的密钥 X，用公钥加密后传输给服务器端。服务端用私钥去解密得到密钥 X，后续双方都通过密钥 X 去加解密传输数据。貌似是个接近完美（安全 + 快速）的方案 ~
文章开头有谈到 TLS 除了传输加密还有完整性验证以及身份认证的作用，那为啥要完整性和身份认证呢？完整性好理解，是为了避免内容被中间人劫持后删除一部分，那身份认证呢？
设想一下：如果中间人劫持到公钥 A，将公钥 A 替换成自己的伪造的公钥 B。浏览器端随机生成一个密钥 X，用公钥 B加密后传输给服务端。中间人再次劫持用自己伪造的私钥 B 去解密得到密钥 X，再用保存的公钥 A 去加密传给服务端。服务端虽然是可以用私钥 A 解密获取密钥 X，但密钥 X 已经泄露了。
身份认证的真相浮出水面，目的就是确保公钥是服务端传输的。
完整性验证
在讲身份认证前，先讲下完整性验证。主要通过数字签名去实现，保证传输内容是完整且没有被篡改的。
摘要
常见的摘要算法有 MD5、SHA-1、SHA-2等，这种加密算法是不可逆的，TLS 中使用的是SHA-2。将传输内容经摘要算法哈希后就得到我们的摘要。
数字签名
非对称加密的逆运用。服务端用私钥去加密摘要实现数字签名，附加到原文末尾传输给浏览器端。浏览器端用服务端传输的公钥去解密数字签名获取摘要信息，并将原文哈希（相同的哈希算法）得到另一份摘要。比对两份摘要，若一致，则证明了传输内容的完整性。
这里还有两个疑问。
- 数字签名会被中间人劫持更改么？
因为中间人没有私钥，所以无法劫持更改原文后再加密生成数字签名。
- 数字签名前为什么需要哈希？
原文信息过长，非对称加密时间消耗更大，经过哈希后为文本内容缩短，进而缩短加密时间。
身份认证
身份认证，需要权威机构的认证，才具备信服力，这个机构就是CA（Certificate Authority）。只有 CA 颁布具有认证过的公钥，才能解决公钥的信任问题。CA 会将公钥信息放入数字证书颁发给申请者。
数字证书
网站申请 HTTPS 前，都需要向 CA 机构申请一份数字证书。数字证书中包含证书持有者、证书有效期、公钥等信息。服务器把证书传输给浏览器端，浏览器端从证书里获取公钥即可。
这里也有两个疑问？
- 数字证书被中间人劫持替换会有影响么？
数字证书里携带了网站信息（包含域名），与请求域名比对是否一致，就能判断是否被掉包。
- 怎么确保数字证书的可信度？
数字证书的验证过程还有一个证书信任链的问题。操作系统和浏览器都会内置一些根证书，如果当前证书的签发者不是根证书，则会根据证书中的签发者去向 CA 机构请求该中间证书，再获取中间证书的签发者，根据签发者再去请求 CA 机构，若获取的证书没有上级签发机构，则证明是根证书。检查根证书是否在预载的根证书清单上，确保当前证书是否可信。当然，这条信任链中间步骤可能会更多，这也更加严格的保证证书的可信度。
HTTPS 流程
最后，讲述下 HTTPS 加解密流程，串联总结所有的知识点。
- 浏览器端发起 HTTPS 请求，默认使用 443 端口进行连接，请求包含支持的 TLS 协议版本、随机数Random1、支持的加密套件。
- HTTPS 需要一份 CA 颁发的数字证书，数字证书包含证书持有者、证书有效期、公钥等信息。CA 颁发的私钥则存储在服务端不公开。
- 服务端收到浏览器端请求，响应返回请求包含数字证书、随机数 Random2、确认的加密套件。
- 浏览器端收到数字证书后，验证数字证书合法性（是否被篡改、是否被掉包、是否过期等）。不通过，则显示 HTTPS 警告；通过，则浏览器端获取公钥、生成随机数 Random3 且根据三个随机数生成会话密钥。
- 向服务端传输公钥加密后的随机数以及会话密钥加密的浏览器端完成的握手信息。
- 服务端用私钥解密获取随机数Random3，根据三个随机数使用相同算法生成会话密钥，用会话密钥验证浏览器端传输的握手信息且加密服务端完成的握手信息。
- 将会话密钥加密的握手完成信息返还给浏览器端。
- 浏览器端用会话密钥解密服务端返还的数据，验证 TLS 握手结束。
- 后续 HTTPS 请求都用会话密钥加解密通信。
其中生成三个随机数的目的还是增加安全性，防止被暴力破解。
TLS 四次握手
上述流程就是 TLS 四次握手的大概过程，现在我们将流程划分一下。
第一次握手：① 。
第二次握手：② ③ 。
第三次握手：④ ⑤ 。
第四次握手：⑥ ⑦ ⑧ 。
成功完成四次握手后，后续数据均可用当前会话密钥加解密。
参考
彻底搞懂HTTPS的加密原理
SSL/TLS协议运行机制的概述
SSL/TLS、对称加密和非对称加密和TLSv1.3
计算机网络模型到底是七层？五层？四层？
对称加密与非对称加密
5 Differences Between Symmetric vs Asymmetric Encryption
数字签名是什么？
数字签名原理及作用
What is the difference between a digital signature and a digital certificate
SSL/TLS协议四次握手
