HTTPS 的安全加密逻辑

1. 认识 HTTPS

HTTPS 属于应用层网络协议，是 HTTP 的安全升级版本，核心是在原有 HTTP 协议的基础上，新增了一层数据加密传输层。

原始的 HTTP 协议以纯文本形式明文传输数据，这就导致数据在网络传输的过程中，极易被第三方截获、篡改，存在极大的安全漏洞。

1.1 让人防不胜防的 “运营商劫持”

我们以下载天天动听播放器这个场景为例，就能直观感受到运营商劫持带来的影响：正常情况下，点击下载按钮，页面会直接弹出该应用的官方下载链接；可一旦遭遇运营商劫持，点击相同的下载按钮，弹出的链接会被替换成 QQ 浏览器的下载地址。

用户在网络中发送的所有数据报文，都会途经运营商的路由器、交换机等网络设备，这些设备能够直接解析出数据的具体内容，进而对其进行恶意篡改。

其实点击 “下载按钮” 这个操作，本质是向服务器发送了一条 HTTP 请求，服务器返回的 HTTP 响应里，就包含了对应 APP 的下载链接。运营商劫持后，识别出该请求的目的是下载天天动听，就会自动把返回给用户的响应内容篡改，将下载地址替换成 QQ 浏览器的。

不仅是运营商，黑客也能通过类似的技术手段实施数据劫持，轻则篡改传输内容，重则窃取用户的账号、密码等隐私信息。试想一下，若黑客在用户登录支付宝时，截获到账户余额甚至支付密码，会造成多大的财产损失。

由此可见，网络中的明文传输存在极高的安全风险，而 HTTPS 正是通过在 HTTP 基础上做加密处理，从根本上提升了数据传输的安全性，保障用户的信息安全。

1.2 什么是加密？

所谓加密，就是把需要在网络中传输的原始明文信息，经过一系列特定算法变换，转换成无法直接识别的密文；解密则是加密的逆向操作，通过对应的算法把密文还原为原本的明文。

在加密和解密的整个流程中，通常需要借助一个或多个专用辅助数据来完成操作，这类起到关键作用的辅助数据就是密钥（标准读音为 yuè，四声，日常交流中大家也常读作 yào，四声）。

如今，加密与解密技术已经发展成为一门独立的学科 —— 密码学。而密码学的奠基人，正是计算机科学的先驱艾伦・麦席森・图灵，计算机领域的最高荣誉 “图灵奖”，便是以他的名字命名的。

2. HTTPS 的加密工作流程

想要实现网络数据的安全传输，核心手段就是对数据进行加密处理，让网络中传输的不再是可直接读取的明文，而是经过加密后的密文。

目前主流的数据加密方式主要分为两大类别：对称加密和非对称加密，HTTPS 的安全传输体系，正是结合这两种加密方式的优势构建而成的。

2.1 先引入：对称加密

对称加密的核心逻辑，是使用同一把密钥完成数据的加密和解密操作：用这把密钥能把明文加密成密文，同样也能通过这把密钥将密文还原为明文。

按位异或运算是最基础的对称加密方式，我们用一个简单的例子就能理解：假设原始明文为 a，加密密钥为 key，将 a 和 key 进行按位异或运算，就能得到密文 b；再把密文 b 和同一密钥 key 做一次按位异或运算，就能还原出最初的明文 a。比如 a=1234、key=147 时，运算后得到的密文 b=1089。如果是对字符串进行对称加密，原理也是如此，只需将每个字符转换为对应的数字后再执行运算即可。

当然，按位异或只是入门级的对称加密方式，HTTPS 实际并未采用这种简单的加密手段。

引入对称加密后，即便传输的密文被黑客截获，由于其无法获取对应的密钥，也就无法对密文进行解密，自然无法知晓数据的真实内容。

但这一方式存在明显的弊端：服务器需要同时为海量客户端提供服务，若多个客户端共用同一密钥，密钥极易泄露，造成全网安全风险；若为每个客户端单独分配专属密钥，服务器又需要维护庞大的 “客户端 - 密钥” 对应关系，操作成本极高且难以实现。

理想的解决办法是，在客户端与服务器建立网络连接的瞬间，双方实时协商确定本次通信的专属密钥。但新的问题随之而来：通信双方该如何安全传输这份对称密钥呢？

显然，对称密钥不能通过明文方式传输；而如果用对称加密的方式对密钥本身进行加密，就会陷入 “先有鸡还是先有蛋” 的逻辑循环。由此可见，仅依靠对称加密，无法解决 HTTPS 的全链路加密传输问题。

2.2 再补充：非对称加密

为了解决对称密钥的安全传输难题，HTTPS 引入了非对称加密方式。这种加密方式需要用到一对相互配对的密钥，分别是公钥和私钥，不过非对称加密有一个显著缺点：运算速度远低于对称加密。

非对称加密有两种核心使用模式：

1. 用公钥对明文进行加密，生成的密文只能通过对应的私钥解密，还原为明文；
2. 反向操作，用私钥对明文加密后，生成的密文只能通过对应的公钥解密。

我们可以用一个生活化的场景来理解非对称加密：A 打算给 B 送一份重要文件，但不确定 B 是否在现场，于是两人提前约定：B 给 A 一把可公开的锁（对应公钥），A 把文件放进盒子后用这把锁锁好，B 只需用自己独有的钥匙（对应私钥），就能打开盒子取出文件。

在这个场景中，公钥可以随意分发给任何人，无需担心泄露；而私钥只有持有者本人拥有，是解密的唯一关键。

结合两种加密方式的优劣，HTTPS 采用了 “混合加密” 的策略：由于对称加密的传输效率更高，因此仅在协商对称密钥的阶段使用非对称加密；一旦双方确定了本次通信的对称密钥，后续所有的网络数据传输，均采用对称加密方式。

但这种混合加密方式并非绝对安全，黑客仍可通过伪造公钥的手段，实施中间人攻击，进而窃取通信的对称密钥。

2.3 最大隐患：中间人攻击

中间人攻击是黑客窃取 HTTPS 通信对称密钥的主要手段，我们结合服务器和中间人各自的非对称加密密钥体系，拆解这种攻击的具体流程（服务器拥有公钥 S1、私钥 S2；中间人拥有公钥 M1、私钥 M2）：

1. 客户端向服务器发起网络连接请求，服务器将自身公钥 S1 以明文形式发送给客户端；
2. 中间人截获该数据报文，提取并保存 S1，随后将报文中的 S1 替换为自己的公钥 M1，把伪造后的报文发送给客户端；
3. 客户端收到报文后，误以为 M1 是服务器的公钥，随即生成本次通信的对称密钥 X，并用 M1 对 X 加密，将报文发送给服务器；
4. 中间人再次截获报文，用自己的私钥 M2 解密，直接获取对称密钥 X，再用保存的 S1 对 X 重新加密，将报文转发给服务器；
5. 服务器收到报文后，用自身私钥 S2 解密，得到对称密钥 X，误以为这是与客户端直接协商的结果；
6. 客户端和服务器开始使用 X 进行对称加密通信，但所有传输数据都在中间人的掌控中，黑客可随意截获、窃听甚至篡改数据。

那么，该如何从根本上破解中间人攻击，保障服务器公钥的真实性呢？

2.4 终极解决方案：引入数字证书

解决中间人攻击的核心，是让客户端能够准确验证服务器公钥的合法性，HTTPS 的解决方案是：服务器在使用 HTTPS 协议前，需向权威的 CA（数字证书认证中心）申领一份数字证书。

这份证书相当于服务器的 “网络身份证”，包含了服务器的身份信息、公钥信息等关键内容，客户端只需从证书中提取公钥，就能确认其权威性。服务器将证书传输给浏览器，浏览器无需直接接收服务器的公钥，从根源上避免了公钥被伪造的问题。

数字证书本质是一个结构化的字符串，核心包含以下信息：

1. 证书的发布机构（CA 机构）；
2. 证书的有效使用期限；
3. 服务器的公钥；
4. 证书的所有者（对应服务器）；
5. 数字签名；
6. 其他相关附加信息。

需要注意的是，服务器在申请数字证书时，需在指定平台同步生成一对公钥和私钥，这对密钥会专门用于网络通信中的明文加密和数字签名操作。

2.4.1 搞懂：数字签名

数字签名的生成同样基于非对称加密算法，需注意其密钥体系与 HTTPS 通信的公钥私钥相互独立，切勿将二者混淆。

当服务器向 CA 机构申请数字证书时，CA 机构会先对服务器的真实身份进行严格审核，审核通过后，为该服务器生成专属的数字签名，具体步骤如下：

1. CA 机构拥有一套专属的非对称加密密钥对：私钥 A 和公钥 A’；
2. CA 机构对服务器申请证书的明文数据进行哈希运算，生成唯一的数据摘要；
3. CA 机构用自身的私钥 A 对该数据摘要加密，生成的密文就是这份证书的数字签名 S。

最终，服务器的证书明文与数字签名 S 结合在一起，就构成了可对外发布的数字证书，由 CA 机构正式颁发给服务器。

2.4.2 数字证书如何破解中间人攻击

在客户端与服务器建立网络连接的初始阶段，服务器会先将数字证书发送给客户端，客户端通过对证书进行一系列严格校验，确认服务器公钥的真实性，从根源上杜绝中间人攻击的可能，具体流程分为两步：

第一步：客户端对数字证书做合法性校验

客户端获取证书后，会依次完成三项校验，确认证书未被伪造或篡改：

1. 校验证书是否在有效期限内，若已过期则直接判定为无效；
2. 校验证书的发布机构是否为受信任的 CA 机构，操作系统中会内置权威 CA 机构列表，非列表内机构颁发的证书会被标记为可疑；
3. 校验证书是否被篡改：从系统中提取该 CA 的公钥，对证书的数字签名解密，得到哈希值 hash1（即 CA 生成的原始数据摘要）；再对整个证书的明文内容做哈希运算，得到哈希值 hash2；对比 hash1 和 hash2，若二者完全一致，说明证书未被篡改，反之则判定证书无效。

第二步：中间人无法篡改或伪造数字证书

结合证书的校验逻辑，中间人想要通过证书实施攻击，几乎没有可行途径：

1. 若中间人篡改证书明文，因没有 CA 机构的私钥，无法对篡改后的明文重新哈希并加密生成新签名，只能保留原签名；客户端校验时会发现 hash1 和 hash2 不一致，直接判定证书无效，终止数据传输；
2. 若中间人试图替换整个证书，用自己申请的合法证书掉包服务器证书，证书明文中的域名、服务器身份等信息会与客户端请求的目标不一致，客户端能直接识别异常，终止通信；
3. 若中间人试图伪造假证书，因没有 CA 私钥，无法生成合法的数字签名，伪造的证书会在客户端校验环节直接被驳回。

简言之，中间人因无法获取 CA 机构的私钥，既无法篡改合法证书，也无法伪造有效证书，从而彻底失去了实施中间人攻击的条件。

3. HTTPS 加密体系核心总结

在 HTTPS 的整个工作流程中，一共涉及三组功能不同的密钥，这三组密钥各司其职、相互配合，共同构建起 HTTPS 的全链路安全加密体系：

1. 第一组（非对称加密密钥）：由 CA 机构持有，专门用于客户端校验服务器的数字证书，确认证书未被篡改或伪造；
2. 第二组（非对称加密密钥）：由服务器持有，用于客户端与服务器协商生成本次通信的对称密钥，解决了对称密钥的安全传输问题；
3. 第三组（对称加密密钥）：由客户端和服务器在通信初期临时协商生成，是双方后续所有数据传输的核心密钥，客户端和服务器的所有明文数据，都会通过该密钥加密为密文后再进行网络传输。