第13讲：HTTPS 协议原理

HTTPS 是什么

HTTPS 可以理解为运行在 TLS 之上的 HTTP。TLS 不仅提供加密，还提供完整性保护和身份认证。

HTTP 本身不会加密应用数据；无论载荷是文本还是二进制数据，在没有 TLS 保护时，沿途节点都可能看到或篡改其内容。

概念准备

1. 什么是"加密"

加密就是把明文（要传输的信息）进行一系列变换，生成密文。

解密就是把密文再进行一系列变换，还原成明文。

在加密和解密的过程中，往往需要一个或多个中间数据来辅助完成变换，这样的数据称为密钥。

加密与解密如今已经发展成一门独立的学科：密码学。密码学的奠基人之一，也是计算机科学的先驱之一：艾伦·麦席森·图灵。

2. 为什么要加密

运营商劫持

以下载"天天动听"为例。

未被劫持时，点击下载按钮会弹出天天动听的下载链接：

被劫持后，点击下载按钮却会弹出 QQ 浏览器的下载链接：

网络传输的任何数据包都会经过运营商的网络设备（路由器、交换机等）。运营商的设备可以解析传输的数据内容，并对其进行篡改。

点击"下载"按钮，本质上是向服务器发送一个 HTTP 请求；服务器返回的 HTTP 响应中包含应用的下载链接。发生运营商劫持后，运营商发现这是下载天天动听的请求，便把返回给用户的下载地址替换成 QQ 浏览器的下载地址。

因为 HTTP 使用明文传输，数据会经过路由器、Wi-Fi 热点、通信服务运营商、代理服务器等多个物理节点。一旦信息在传输过程中被劫持，内容便会完全暴露；劫持者还可以篡改信息而不被通信双方察觉，这就是中间人攻击。因此，我们需要对信息进行加密。

思考：运营商为什么要进行劫持？

不仅运营商可以劫持数据，其他攻击者也可以使用类似手段窃取用户隐私信息或篡改内容。试想，如果攻击者在用户登录支付宝时获取到账户余额，甚至支付密码，后果将非常严重。

在互联网上，明文传输是比较危险的事情 。HTTPS 通过 TLS 为 HTTP 提供加密、完整性保护和身份认证，进一步保障用户的信息安全。

3. 常见的加密方式

对称加密

采用单钥密码系统：同一个密钥既用于信息加密，也用于信息解密。其特征是加密和解密使用相同的密钥。
常见对称加密算法（了解）：DES、3DES、AES、TDEA、Blowfish、RC2 等。
特点：算法公开、计算量小、加密速度快、加密效率高。

对称加密就是通过同一个密钥把明文加密成密文，并把密文解密回明文。

一个简单的对称加密示例是按位异或。

假设明文 a = 1234，密钥 key = 8888：

加密：a ^ key = 9834，得到密文 b = 9834。

解密：b ^ key = 1234，还原出明文 1234。

字符串也可以采用同样的思路，因为每个字符都可以表示成一个数字。不过，按位异或只是最简单的对称加密，HTTPS 并不直接使用这种方式。

非对称加密

非对称加密需要两个配对的密钥：公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。
常见非对称密码算法包括 RSA；常见数字签名算法包括 DSA、ECDSA（了解）。
特点：算法复杂，安全性依赖于算法和密钥；加密、解密速度通常比对称加密慢。

公钥和私钥相互配对。公钥可以公开，私钥则必须由持有者妥善保管。在本课的简化模型中，可以这样理解：

用公钥加密明文，再用私钥解密密文。
也可以用私钥对摘要进行签名，再用公钥验证签名。

非对称加密涉及数论等知识。可以用一个生活中的例子帮助理解：

A 要给 B 一些重要文件，但 B 可能不在。B 事先告诉 A："桌上有一个盒子，我给你一把锁。你把文件放进盒子并锁上，我回来后用钥匙开锁取文件。"

在这个场景中，锁相当于公钥，钥匙相当于私钥。锁可以交给任何人，但钥匙只有 B 自己持有，只有持有私钥的人才能解密。

4. 数据摘要与数据指纹

数字指纹（数据摘要）的基本原理，是利用单向散列函数（Hash 函数）对信息进行运算，生成一串固定长度的数字摘要。数字指纹不是一种加密机制，但可以用来判断数据是否被篡改。
常见摘要算法有 MD5、SHA-1、SHA-256、SHA-512 等。算法将无限的数据空间映射到有限的摘要空间，因此理论上可能发生碰撞（两个不同的信息得到相同摘要）。MD5 和 SHA-1 已不具备安全的抗碰撞性，只适合作为本课原理示例；安全场景应采用当前仍被认可的算法，例如 SHA-256。
摘要与加密算法的区别在于：摘要严格来说不是加密，因为不存在解密过程，而且很难从摘要反推出原始信息。摘要通常用于数据比对。

5. 数字签名

摘要经过私钥签名后，就得到数字签名，后文会详细说明。

6. 理解链：承上启下

对 HTTP 进行对称加密，能否解决数据通信安全问题？问题是什么？
为什么要使用非对称加密？为什么不全部使用非对称加密？

HTTPS 的工作过程探究

要保证数据安全，就需要进行加密。网络中不再直接传输明文，而是传输加密后的密文。加密方式很多，但整体可以分成两大类：对称加密 和非对称加密。

方案 1：只使用对称加密

如果通信双方各自持有同一个密钥 K，且没有其他人知道，那么只要密钥没有泄露，双方通信的机密性就可以得到保护；完整性和身份认证还需要额外机制。

引入对称加密后，即使数据被截获，由于攻击者不知道密钥，也无法直接解密并获知请求的真实内容。实际协议还会使用消息认证码或认证加密来检测篡改。

但事情没有这么简单。服务器同一时刻会为很多客户端提供服务，每个客户端使用的密钥必须不同，否则密钥很容易扩散。因此，服务器需要维护每个客户端与对应密钥之间的关联关系，这会带来较高的管理成本。

更理想的做法，是在客户端和服务器建立连接时，由双方协商确定本次会话使用的密钥。

如果直接明文传输密钥，攻击者也能得到密钥，后续加密便形同虚设。因此，密钥本身也必须加密传输。

但如果仍使用对称加密来保护密钥，就需要先协商一个"密钥的密钥"，陷入"先有鸡还是先有蛋"的问题。因此，密钥传输不能只依赖对称加密。

方案 2：只使用非对称加密

如果服务器先把公钥以明文方式传给浏览器，浏览器之后发送数据前都先用该公钥加密，那么从客户端到服务器的信道看似安全，因为只有服务器持有对应私钥，能够解开公钥加密的数据。

但是，服务器到浏览器的信道如何保证安全？

如果服务器用私钥对数据签名，浏览器可以用公钥验证数据来源，但这并不能提供服务器到浏览器方向的机密性，因为公钥本来就是公开的，任何中间人都可以取得它。因此，只使用非对称密码机制仍不能同时解决双向机密性、效率和身份认证问题。

方案 3：双方都使用非对称加密

服务端拥有公钥 S 与对应私钥 S'，客户端拥有公钥 C 与对应私钥 C'。
客户端和服务端交换公钥。
客户端向服务端发送信息时，先用 S 加密数据，再发送；只有拥有 S' 的服务器能够解密。
服务端向客户端发送信息时，先用 C 加密数据，再发送；只有拥有 C' 的客户端能够解密。

这种方案看似可行，但仍存在两个问题：

效率太低。
依旧存在安全问题。

方案 4：非对称加密 + 对称加密

先解决效率问题：

本节沿用传统 RSA 密钥传输模型 来说明混合加密：客户端生成会话密钥，再用服务端公钥加密传输。现代 TLS 1.3 通常使用 (EC)DHE 协商共享秘密，并由证书对应的私钥签名握手数据来完成身份认证，不再用 RSA 直接传输会话密钥。

服务端持有非对称加密的公钥 S 和私钥 S'。
客户端发起 HTTPS 请求，获取服务端公钥 S。
客户端在本地生成对称密钥 K，使用公钥 S 加密后发送给服务器。
中间网络设备没有私钥，即使截获数据，也无法还原明文或获得对称密钥 K。但这个结论还有前提，后文会继续讨论。
服务器用私钥 S' 解密，得到客户端发送的对称密钥 K，并使用该密钥加密返回给客户端的响应数据。
后续客户端和服务器之间的通信只使用对称加密。只有客户端和服务器知道该密钥，其他主机或设备即使截获数据，也无法直接获知明文。

由于对称加密的效率比非对称加密高很多，因此只在开始阶段协商密钥时使用非对称加密，后续传输仍使用对称加密。

虽然该方案已经比较接近答案，但方案 2、方案 3、方案 4 都存在同一个问题：如果中间人在最初的握手协商阶段就开始攻击，会发生什么？

中间人攻击：针对上面的场景

中间人攻击的英文是 Man-in-the-Middle Attack，简称 MITM 攻击。

https://baike.baidu.com/item/中间人攻击/1739730?fromtitle=MITM攻击\&fromid=15637385

在方案 2、方案 3、方案 4 中，客户端获得公钥 S 后，使用它加密本地生成的对称密钥 K。中间人即使截获密文，也无法解出 K，因为只有服务器持有私钥 S'。

但是，如果攻击发生在最初的握手协商阶段，情况就不同了。假设攻击者已经成功成为中间人：

服务器持有公钥 S 和私钥 S'。
中间人持有公钥 M 和私钥 M'。
客户端向服务器发起请求，服务器明文发送公钥 S 给客户端。
中间人劫持报文，提取并保存公钥 S，然后把报文中的 S 替换成自己的公钥 M，再把伪造报文发送给客户端。
客户端收到报文后提取公钥 M，但并不知道公钥已被替换。客户端生成对称密钥 K，用 M 加密 K，再把报文发送给服务器。
中间人劫持报文，用自己的私钥 M' 解密并得到通信密钥 K；随后再用之前保存的服务端公钥 S 加密 K，把报文转发给服务器。
服务器收到报文，用自己的私钥 S' 解密，得到通信密钥 K。
双方开始使用 K 进行对称加密通信，但一切都在中间人的掌握中：中间人可以劫持数据、窃听，甚至修改内容。

上述攻击同样适用于方案 2 和方案 3。

问题的本质是：客户端无法确认包含公钥的报文确实来自目标服务器。

引入证书

CA 认证

服务端在使用 HTTPS 前，需要向 CA 机构申领数字证书。数字证书中包含证书申请者信息、公钥信息等。服务器把证书发送给浏览器，浏览器再从证书中取得公钥。证书类似身份证，用于证明服务端公钥的权威性。

https://baike.baidu.com/item/CA认证/6471579?fr=aladdin

证书可以理解成一个结构化的数据，其中包含：

证书发布机构。
证书有效期。
公钥。
证书所有者。
签名。
其他扩展信息。

申请证书时，需要在特定平台生成一对密钥，即公钥和私钥。这对密钥用于网络通信中的数据保护和数字签名。

其中，公钥会随 CSR 文件一起提交给 CA 进行认证；私钥由服务端自行保留，供后续通信使用，在本课的简化流程中主要用于交换对称密钥。

可以在线生成 CSR 和私钥。形成 CSR 后，需要向 CA 申请认证；实际认证流程通常较为繁琐，可以通过证书服务商完成。

理解数字签名

数字签名基于非对称密码算法。这里先单独理解签名机制，暂时不要与 HTTPS 通信阶段使用的服务端密钥对混淆。

服务端申请 CA 证书时，CA 机构会审核服务端，并为该网站生成数字签名。过程如下：

CA 机构持有一对非对称密钥：私钥 A_priv 和公钥 A_pub。
CA 对服务端申请的证书明文数据进行 Hash 运算，形成数据摘要。
CA 使用私钥 A_priv 对数据摘要进行签名，得到数字签名 Sig。

服务端申请的证书明文与数字签名 Sig 共同组成数字证书，随后由 CA 颁发给服务端。

方案 5：非对称加密 + 对称加密 + 证书认证

客户端与服务器刚建立连接时，服务器向客户端返回一个证书。证书中既包含服务端的公钥，也包含网站的身份信息。

客户端进行认证

客户端取得证书后，会对证书进行校验，以防止收到伪造证书：

判断证书是否处于有效期内。
验证证书链能否连接到操作系统或浏览器信任的根证书。
检查访问的主机名是否与证书的 SAN（主题备用名称）匹配。
使用签发者公钥和证书声明的签名算法，验证证书待签名部分（tbsCertificate）上的签名。教学上可以把它理解为：签名所对应的摘要 hash1 与对证书待签名部分重新计算的摘要 hash2 必须一致；实际验签算法不一定会"还原出摘要"。

查看浏览器的受信任证书发布机构

在 Chrome 浏览器中，点击右上角的菜单按钮：

选择"设置"，搜索"证书管理"，即可进入证书管理界面；若未直接找到，可在"隐私设置和安全性 → 安全"中查找。

中间人能否篡改证书

中间人可以尝试篡改证书明文。
但中间人没有 CA 机构的私钥，无法为篡改后的证书生成匹配的合法签名。
如果强行篡改，客户端验证时会发现证书明文的摘要与签名所对应的摘要不一致，从而认定证书不可信，并终止向服务器传输敏感信息。

中间人能否整体掉包证书

中间人没有 CA 私钥，因此无法自行制作受信任 CA 签发的假证书。
中间人可以向 CA 申请一张真实证书，再尝试用自己的证书整体替换目标证书。
但证书明文中包含域名等服务端身份信息。证书被整体替换后，客户端仍可通过域名等信息发现证书与目标服务器不匹配。
中间人没有 CA 私钥，因此不能对任何已签发证书进行合法修改，包括自己申请的证书。

常见问题

为什么摘要需要用私钥签名

课件使用 MD5 说明摘要的基本性质。MD5 已不适合安全签名或抗篡改场景，这里只作为原理示例：

定长：无论源字符串多长，MD5 摘要始终为 16 字节，通常写成 32 个十六进制字符；俗称的"16 位 MD5"一般只是完整摘要的截取表示。

分散：源字符串只改变一点，最终得到的 MD5 值通常也会有很大差异。

不可逆 ：由源字符串计算 MD5 很容易，但仅凭 MD5 摘要在计算上很难还原原始字符串。

在不考虑主动攻击的普通数据比对中，相同摘要通常可作为内容相同的强提示；安全场景还要求摘要算法具备足够的抗碰撞性，并通过数字签名等机制保护摘要与原文的绑定关系。

理解判定证书篡改的过程

可以把这个过程类比为判断身份证是否伪造。

假设证书只是一个简单的字符串 hello。其完整 MD5 为 5D41402ABC4B2A76B9719D911017C592；课件为便于展示，使用中间 16 个十六进制字符 BC4B2A76B9719D91 作为示例值。

如果 hello 中有任意字符被篡改，例如变成 hella，完整 MD5 会变为 6E4A858CBDBD6F9CF51F2FD89D8C7558；课件展示的中间 16 位是 BDBD6F9CF51F2FD8。

服务器把 hello 和摘要 BC4B2A76B9719D91 一起返回给客户端。客户端重新计算 hello 的摘要，并检查结果是否等于 BC4B2A76B9719D91，即可判断数据是否发生变化。

但如果攻击者不仅把 hello 改成 hella，还重新计算并替换摘要，客户端便无法仅凭明文摘要识别篡改。

因此，传输的摘要不能不受保护。CA 先对证书明文进行 Hash 运算形成摘要，再使用自己的私钥对摘要进行签名；证书明文与签名共同组成 CA 证书并颁发给服务端。客户端请求时，服务端把证书发给客户端。中间人即使截获证书，因为没有 CA 私钥，也无法在修改证书后生成合法签名。

最后，客户端使用证书链中签发者的公钥，按照证书声明的签名算法验证 tbsCertificate 上的签名。验证通过，说明签名覆盖的证书内容未被篡改，且签名者持有与签发者公钥匹配的私钥。

为什么签名不直接处理整份数据，而要先形成摘要

摘要的长度固定且远小于原始数据。对摘要进行签名，可以缩短签名运算所处理的数据长度，提高签名生成和验证的效率。

如何成为中间人（了解）

ARP 欺骗 ：在局域网中，攻击者通过接收 ARP Request 广播包，可以获知其他节点的 (IP, MAC) 地址。例如，攻击者获知主机 A、B 的地址后，向 B（受害者）谎称自己是 A，使 B 原本发给 A 的数据包被攻击者截获。
ICMP 攻击 ：ICMP 协议包含重定向报文类型。攻击者可以伪造 ICMP 信息并发送给局域网中的客户端，把自己伪装成更优的路由路径，从而让目标的上网流量发送到攻击者指定的接口，达到与 ARP 欺骗类似的效果。
假 Wi-Fi、假网站等。

完整流程

下图左侧是客户端完成的工作，右侧是服务器完成的工作。

总结

HTTPS 工作过程中涉及三组关键密钥：

第一组：CA 签名与验签密钥（非对称） 。CA 持有签名私钥，客户端的操作系统或浏览器持有受信任 CA 的公钥。服务器返回携带 CA 签名的证书；客户端用 CA 公钥验证证书的完整性和来源，进而确认其中服务端公钥的可信性。
第二组：服务端密钥对（非对称） 。证书中包含服务端公钥，服务端持有对应私钥。在课件采用的传统 RSA 密钥传输模型中，客户端用可信的服务端公钥加密随机生成的对称密钥，服务器再用私钥解密。现代 TLS 1.3 通常使用服务端私钥签名握手，并通过 (EC)DHE 协商共享秘密。
第三组：会话密钥（对称）。客户端与服务器后续传输的数据，都使用协商得到的对称密钥进行加密和解密。

一切的关键都围绕用于会话通信的对称密钥展开，其他机制都在辅助它安全地建立并工作：

在课件的传统 RSA 模型中，第二组非对称密钥用于安全传输对称密钥；在现代 TLS 1.3 中，它主要用于认证握手，双方通过 (EC)DHE 导出会话密钥。

第一组 CA 非对称密钥用于验证证书，使客户端能够信任证书中携带的服务端公钥。