一、为什么需要 HTTPS？先看 HTTP 的 "裸奔" 困境
在 HTTPS 出现之前，我们访问网站用的都是 HTTP 协议。但 HTTP 有个致命问题：数据明文传输。就像寄信不封口，中间经过的任何节点（比如路由器、运营商服务器）都能轻松偷看甚至篡改内容。
想象一下：
- 你在购物网站输入的银行卡号，可能被黑客截获；
- 你登录社交账号的密码，在传输过程中如同 "裸奔"；
- 甚至你看到的网页内容，都可能被运营商偷偷植入广告。
这就是为什么 HTTPS 成为了现代互联网的标配 ------ 它给 HTTP 套上了一层加密的 "安全外衣"，让数据传输变得 "不可偷看、不可篡改、不可冒充"。
二、HTTPS 不是 "新协议"，而是 "HTTP + 加密层"
很多人以为 HTTPS 是一种全新的协议，其实不然。简单说：
HTTPS = HTTP + TLS/SSL- HTTP：负责正常的请求和响应（比如 "我要首页内容"、"这是给你的数据"）；
- TLS/SSL：位于 HTTP 和 TCP 之间的加密层（现在主流是 TLS，SSL 是它的老祖宗），负责给数据 "上锁" 和 "解锁"。
打个比方：如果 HTTP 是快递员，那 TLS 就是快递员手里的 "加密保险箱"------ 快递员还是那个快递员，但他运送的东西被放进了只有收件人能打开的箱子里。
三、HTTPS 工作过程（本文不涉及具体的加密算法）
明文（Plaintext）
指在加密前的原始信息或数据。它是人们能够直接阅读、理解或处理的内容，例如一段文字、文件、电子邮件或任何未经过加密处理的消息。明文是加密算法的输入。
密文（Ciphertext）
指经过加密算法处理后得到的、不可直接阅读的内容。密文对没有相应解密密钥的接收者来说是不可理解的，只能通过相应的解密过程恢复为明文。密文是加密算法的输出，用于在不安全的通道（如互联网）中安全传输信息。
1 引入对称加密
生成一个密钥（密钥可以由客户端生成也可以由服务器生成），明文到密文通过这个密钥进行，密文到明文也通过这个密钥进行。
预期结果：
此时客户端给服务器发送的是通过 key 进行对称加密的密文。
黑客就算知道数据是啥，由于没有密钥，也就无法知道明文。
服务器收到数据之后，使用同样的密钥对数据进行解密。
问题缺陷：
1 如何有多台设备进行访问服务器，那么这个密钥是所有客服端共有一个？答案是否，每个客服端有自己单独的密钥。
2.无论是客户端生成密钥还是服务器端生成，首先都需要把密钥发送给对方，问题就出现在在发送的工程中。这时候非法设备他是可以在传输过程中拿到密钥然后对其信息破解的。
问题：需要告诉对方密钥是啥，但是密钥不能明文传输～～
比如如果对密钥再进行一次对称加密.
比如密钥是 key, 使用另一个密钥 key2 针对 key 进行加密，把 key 密文传输给对端～～
如果不把 key2 告诉服务器，服务器也解密不了，拿不到 key如果把 key2 告诉服务器，又会被黑客获取到～～
2 引入非对称加密
非对称加密可以简单理解为：
有两把 "配对" 的钥匙------ 公钥（可以公开给所有人，比如放到网上）和私钥（自己偷偷保存，绝不外传）。这两把钥匙不是凭空产生的，是数学家研究出的、互相之间有特殊数学关系的数据。
加密解密规则是：
- 用公钥 加密的数据，只有对应的私钥才能解密；
- 用私钥 加密的数据，只有对应的公钥才能解密。
（比如，你用别人公开的公钥加密了一封秘密信件，只有对方拿着自己的私钥才能看懂内容；反过来，对方用私钥加密一段信息发给你，你用他的公钥就能解开，还能证明这段信息确实是他发的。）
1. 对称加密的 "小缺点"
对称加密本身能安全保护数据，但对称密钥的传输是个难题（比如你和朋友要共用一个密码加密消息，这个密码怎么安全送到朋友手里？直接发容易被黑客截走）。
2. 非对称加密的 "核心作用"
引入非对称加密，主要就是为了安全传递对称密钥 （相当于用非对称加密把 "对称密钥" 锁起来，对方拿到后，用自己的密钥解开，就能得到安全的对称密钥了）。
3. 为啥不全程用非对称加密传数据？
因为非对称加密的计算成本太高（加密、解密过程特别费资源和时间），如果用它传大量网页、图片这类数据，速度会很慢，影响上网体验。
4. 公钥私钥的 "分工"
非对称加密的公钥和私钥是服务器生成的一对密钥：
- 私钥：服务器自己偷偷藏着，绝不外传；
- 公钥：公开给所有人（就像 "公开的锁"，大家能用它加密信息发给服务器，只有服务器的 "私钥钥匙" 能解开）。
所以我们就用非对称+对称密钥的方式来进行传输数据了，具体的流程图如下图所示（假设公钥私钥是由服务器生成）。PS: 图片来自于网上转载.
3 中间人攻击
黑客可以也是有技术破解的，使用欺上瞒下法。具体如下图所示。
4 引入证书
通过证书解决中间人攻击
在客户端和服务器刚一建立连接的时候，服务器给客户端返回一个证书。这个证书包含了刚才的公钥，也包含了网站的身份信息。
服务端在使用HTTPS前，需要向CA机构申领⼀份数字证书，数字证书里含有证书的发布机构、证书有效期、证书的所有者、证书对应服务器的地址/域名、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明服务端公钥的权威性。
4.1 数字签名
数字签名的作用是证明 "数据（比如证书）没被篡改"，过程可以拆成「生成」和「验证」两步，通俗解释如下：
一、数字签名的生成（公证机构来做）
数字签名可以理解为 **"加密后的校验和"**，用来给数据做 "防伪标记"。步骤是：
- 公证机构（比如颁发 HTTPS 证书的 CA 机构）生成证书后，先对证书内容计算一个校验和（类似给证书生成 "独一无二的指纹"，内容变了，指纹就会变）。
- 公证机构有自己的非对称密钥对 （公钥
pub3对外公开，私钥pri3自己保密），然后用私钥pri3对 "刚才算的校验和" 进行加密，加密后的结果就是数字签名。 - 最后，公证机构把「证书 + 数字签名」一起发出去（比如服务器把带签名的证书给客户端）。
二、数字签名的验证（客户端 / 浏览器来做）
客户端拿到 "证书 + 数字签名" 后，要验证证书是否被篡改过，步骤是：
- 客户端自己算校验和 ：按照和公证机构一样的算法，重新对证书内容计算校验和，得到
checksum1（相当于自己给证书再做一次 "指纹"）。 - 解密数字签名拿原始校验和 ：用公证机构公开的公钥
pub3，对证书里的 "数字签名" 进行解密，得到checksum2（这是公证机构当初算好、并用私钥加密的 "原始指纹"）。 - 对比两个校验和 ：
- 如果
checksum1和checksum2一致，说明证书从生成到传输，没有被篡改过，证书里的公钥是服务器原本的、可信的。 - 如果不一致（比如黑客偷偷改了证书里的公钥），那
checksum1和checksum2就对不上。
- 如果
- 浏览器弹警告：此时客户端 / 浏览器（比如 Chrome）会弹出风险提示（像红色页面），问 "网站有风险，是否继续访问？"------ 大部分人会被吓退，起到保护作用；少数人可能选择继续（但风险自担）。
简单说，数字签名就是用 "私钥加密做防伪"，再用 "公钥解密验真伪"，确保数据没被动手脚～
4.2 问题思考
1. 黑客能篡改证书里的公钥吗？
不能。因为证书有 "校验和（数据指纹）"，一旦黑客改了公钥，客户端（浏览器）会自己重新算一遍校验和，结果和证书里的对不上，直接就能识别出 "证书被篡改了"。
2. 黑客能自己做个假证书，替换服务器的证书吗？
不能。证书里明确写了服务器的域名 / 地址 （比如你访问百度，证书里就得是www.baidu.com）。黑客做的假证书域名肯定不对，浏览器一看就知道 "这不是我要访问的网站"。
3. 黑客能同时篡改公钥和数字签名吗？
不能。数字签名是用公证机构（CA）的私钥加密的，这个私钥只有 CA 自己有，黑客拿不到。所以黑客就算改了公钥，也没法生成 "能通过验证的数字签名"，客户端一解密验证就露馅。
4. 公证机构的公钥怎么到客户端？黑客能伪造吗？
不能。公证机构的公钥不是从网络上随便传的，而是提前内置在操作系统或浏览器里的（比如 Windows、Chrome 出厂时，就把可信 CA 的公钥 "预装" 好了）。黑客没法伪造官方的公钥，塞到你的设备里。
4.3 Fiddle可以抓包的原因
我们在安装Fiddler的时候，也需要安装一个证书。这个工作过程，其实就是在进行中间人攻击，而数据是加密的。
信任安装 Fiddler 的证书，就是允许 Fiddler 进行中间人攻击，Fiddler 会使用自己的证书替换掉服务器返回的证书。
由于 Fiddler 的证书已经被安装信任，所以不会让浏览器报错。Fiddler 通过上述中间人攻击，能拿到对称密钥，进而对所有数据解密，让我们看到抓包结果。