构建互联网的信任基石：TLS与数字证书技术探源

互联网加密技术发展至今，已构建起基于TLS协议的加密与信任机制。然而，这一成果并非一朝一夕达成。人们在“发明加密算法—发现缺陷—改进—新的发明”的循环中历经多轮迭代，才形成了当下互联网上被广泛认可的信任机制。下文将对这一过程展开详细阐述。

对称加密

对称加密是人们最直接能想到的加密手段。简单地说：就是有一个密钥，它可以加密一段信息，也可以对加密后的信息进行解密，和我们日常生活中用的钥匙作用差不多。

经典的对称加密算法

Caesar Cipher（凯撒密码）

假设我们用一个“数字”当作密钥，比如 3。 加密时，把每个字母在字母表中的位置往后移 3 位：

• A → D, B → E, C → F ...X → A, Y → B, Z → C

解密则反之。
虽然凯撒密码很弱，但它展示了对称加密的核心概念：

1. 双方事先共享同一个密钥。
2. 用密钥的规则改变数据。
3. 反向操作用同一个密钥恢复数据。

现代对称加密（AES、ChaCha20）本质上也是这样，只不过它们：

• 用的是复杂得多的数学运算（代替“字母平移”）。
• 密钥位数长得多（128 位、256 位等），防止暴力破解。

对称加密的缺陷

最大的问题就是这个密钥怎么让传输的双方知晓，同时不被别人知道。
如果由服务器生成一个密钥并传输给浏览器，在这个传输过程中密钥被别人劫持到手，那么对称加密就不再安全。

非对称加密

非对称加密算法中，将密钥有两把，一把叫做公钥、一把叫私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。私钥无需外传，因此就有效地避免了密钥传输的问题。
Web服务器将私钥自己保存，将公钥公开给所有客户端。就充分保障了客户端-->服务器这个方向的数据安全。

经典的非对称加密算法-RSA

RSA是非常经典的非对称加密算法，下面结合例子说明RSA算法：

1. 选质数 p=61, q=53n = 61×53 = 3233φ(n) = (p-1)(q-1) = 60×52 = 3120
2. 选 e = 17与φ(n)互质 求 d，满足 (17×d) mod 3120 = 1，解得 d = 2753 公钥：(e,n) ，即(17, 3233)，私钥：(d, n)，即(2753, 3233)
3. 明文 m=65，加密：c = m^e mod n = 65^17 mod 3233 = 2790
4. 解密：m = c^d mod n = 2790^2753 mod 3233 = 65

非对称加密的缺陷

非对称加密相比于对称加密，性能消耗高。粗略来讲，非对称加密的性能比对称加密的性能差若干个数量。

对称加密：AES-256：1–3 GB/s（现代 CPU，如 Intel AES-NI）
非对称加密：RSA-2048：约 1,000–5,000 次操作/秒（单线程，现代 CPU）→ 约 0.2–1 MB/s

正因为性能上的瓶颈，限制了非对称加密的使用场景 -- 不可能用在数据面的传输加密中。

对称加密+非对称加密共同使用

方案

从上面的分析得知，非对称加密的优势在于密钥不泄漏，对称加密的优势在于性能高。于是，人们想出一种方案，综合了这两种算法的优势：用非对称加密来交换对称加密的密钥，保证对称加密的密钥不泄漏，然后用对称加密的密钥做数据传输。方案流程是这样的：

思考题：上图中的随机数R由客户端生成，在客户端加密，由服务器解密。不能由服务端生成，服务端加密，客户端解密。这是为什么？

方案缺陷

对称加密+非对称加密的方案也不完美。

缺陷一：中间人劫持

如果在数据传输过程中，有中间人劫持了数据。

• 中间人对上游的服务器，扮演成一个浏览器
• 中间人对下游的浏览器，扮演成假的web服务器。
• 对上游和下游都分别执行上述的“对称加密+非对称加密共同使用”的算法流程

这样在双方都不会发现异常的情况下，中间人通过一套“狸猫换太子”的操作，掉包了服务器传来的公钥，进而得到了对称密钥。
能够让中间人达成这种目的的根本原因是：浏览器无法确认收到的公钥是不是真实网站的。

缺陷二：前向安全性

前向安全性特指在长期密钥（Long-term Key）被泄露的情况下，过去所进行的加密通信依然安全，攻击者无法解密之前的通信内容。

简单来说，即使你现在的密钥被盗了，你以前的聊天记录也不会被翻出来看。

前向安全性缺陷：

• 用于数据加密的会话密钥（对称加密）通过 RSA（非对称加密） 加密传输。
• 如果服务器私钥被泄露，历史上所有用该私钥加密过的会话密钥都可以被解密。

其攻击方式为如下三个步骤：

数字证书

数字签名

为了解决上述中间人劫持的问题，我们就要尝试“证明网站A是真的网站A”的问题。因此引入了互联网空间中的“身份管理局” -- “CA机构”。CA机构为网站颁发的“身份证”，就是数字证书。持有数据证书的网站，才是“真网站”。

数字证书如何保证在传输过程中不被篡改，如何证明数字证书本身的真实性？使用的技术叫“数字签名”。

WEB服务的供应商去CA机构处登记，把自己的公钥、名字、域名等信息报上去，CA机构拿到这些信息，计算一个Hash值，然后再用CA机构的私钥把Hash值加密，加密后的结果就是数字签名。

登记的信息和这个数字签名合在一起，封装了一个新的文件发给WEB服务的供应商，登记就完成了，而这个新的文件就是数字证书。

浏览器在拿到证书后，把证书里面的信息也计算一遍Hash。再用CA机构的公钥把证书里的数字签名进行解密，得到CA机构计算的Hash，两个一对比，就知道这证书是不是公证人签发的，以及有没有被篡改过了。

信任链

一家CA机构业务量太多忙不过来，于是，在CA机构在全球各地建立了它的代理机构--子CA。子CA的数字证书由它的上级CA签发。

证书之间的认证也不止一层，可以A信任B，B信任C，以此类推，这就是信任链。也就是一连串的数字证书，由根证书为起点，透过层层信任，使终端实体证书的持有者可以获得转授的信任，以证明身份。

通常OS或浏览器都会预置世界上大家普遍认可的根证书。

假设如下场景，来解释一个浏览器收到数字证书后的校验过程：

• CA机构A，签发数字证书给CA机构B
• CA机构B，签发数字证书的网站C
• 一个终端中，只安装了CA机构A的数字证书，未安装CA机构B的数字证书。这时，终端访问网站C...

拿到了网站C的数字证书。但终端中没有CA机构B的证书，那么终端会如何校验网站的身份？

步骤１：建立信任链
建立信任链的关键是获取机构B的证书，一般有两种来源：

• 终端在访问网站C时，在TLS协商过程中，除了下发网站C的证书外，也同时下发机构B的数字证书。发送完整证书链是业界的最佳实践。
• 使用 AIA（Authority Information Access）扩展字段，从证书里指向的 URL 下载 CA B 证书，再继续验证。（较少使用这种来源）

步骤2：校验证书
用上级机构的公钥校验被验证证书的数字签名，逐级校验证书的有效性。

地缘政治中的数字证书信任链问题

从上文可以看出，CA机构有很大的权利。根CA只要撤销一个二级CA的证书，就会导致由二级CA签发的数字证书全部失效。

当前的通用的SSL证书信任根CA：

以上根CA中，没有任何一家是中国机构。
这里就存在风险了，这些机构可能因地缘政治的考量，撤回中国的某一CA或中国的某关键网站的数字证书。这就会导致关键网站的访问出现问题。
最直接的后果是：浏览器访问被撤回证书的网站，会弹出风险提示，需要访问者自行承担风险。继而导致访问者无法得知自己访问的是“真网站”还是“假网站”，让中间人可以盗取访问者向网站发送的信息。
但是，也不用太担心。国家已经替你考虑过这个问题了。中国已建立自主根CA体系：

国内的根CA也在大量的终端上预装。这意味着由这些CA发布的证书在指定的终端上都会被认可。

• CFCA（中国金融认证中心）：预装在鸿蒙OS、统信UOS等国产系统
• SRCA（上海数字证书认证中心）：政务系统专用
• GDCA（数安时代）：通过微软根证书计划加入Windows Trust Store

另外，在国家关键系统中，已广泛采用国密系统。国密系统使用的SM2算法证书，但信任链锚定国内根CA。

DH算法

DH算法主要是为了解决“对称加密+非对称加密共同使用”前向安全性问题。
产生前向安全性问题的本质原因是：对称密钥（确切地说，是用于产生对称密钥的关键元素--随机数）通过非对称加密的方式传输给对方。这导致一旦私钥泄漏，就可以解密历史抓包文件，得到对称密钥，继而解密报文。
是否有一种即使私钥泄漏，也不用担心对称密钥被拿到的算法？

基于Ephemeral Diffie-Hellman（DHE/ECDHE） 的密钥交换：

• 客户端和服务器协商一个临时的密钥对。
• 会话密钥不是通过私钥解密得到的，而是通过 DH 协议动态计算出来的。
• 这些临时密钥在每次连接中都是不同的，且永远不会通过网络发送。所以，你就算拥有服务器证书和私钥，也拿不到用于解密的会话密钥！

ECDHE算法说明：

1. ClientHello（客户端发送）
1. 指定支持的加密套件
2. 发送一个随机生成的临时椭圆曲线公钥(g, n)
3. 比如：客户端生成 x_c, X_c = g^x_c mod n 并发送 X_c
2. ServerHello（服务器响应）
1. 选择加密套件
2. 也生成一个 临时的椭圆曲线公钥(g, n)
3. 比如：服务器生成 x_s, X_s = g^x_s mod n 并发送 X_s
3. 双方使用对方的公钥 + 自己的私钥计算共享密钥
1. 客户端：Z = (X_s)^x_c mod n
2. 服务器：Z = (X_c)^x_s mod n
3. Z = g^x_c^x_s mod n
4. 利用 Diffie-Hellman 原理，计算结果一致但无中间泄露
4. 基于共享密钥 Z 再生成实际会话中使用的 session key

任意一方的（x_c 或 x_s）都没有通过网络来发送，取而代之的，通过网络发送的是X_c = g^x_c mod n和X_s = g^x_s mod n（从数学原理上说：X_c很难逆向推出x_c）。且每个会话的密钥都是临时生成的，各不相同。因此私钥的泄漏不能解密旧报文。

DH算法，既不是对称加密，也不是非对称加密。

TLS

把上面提及的对称加密+非对称加密+数字证书+DH算法结合起来，就组成了TLS的基础。

TLS中，“加密套件”是一个打包的安全算法组合，它定义了通信双方如何：

• 建立密钥（密钥交换算法）
• 验证身份（认证算法）
• 加密数据（对称加密算法）
• 保证数据完整性（消息认证码算法 / MAC Algorithm 或 AEAD 模式下的哈希）

可以把它理解为一份“安全协议菜单”，双方在 TLS 握手时通过协商选定其中一个套件，后续通信就按照这个套件的算法规则来执行。
TLS1.2及更早的版本

<密钥交换算法>-<认证算法>-<对称加密算法>-<哈希算法> 例：ECDHE-RSA-AES256-GCM-SHA384

TLS 1.3 精简了加密套件的结构：

• 不再单独指定密钥交换和认证算法（由握手阶段和证书类型决定），把密钥交换算法和认证算法 从加密套件里拆出来，通过 扩展字段（Extensions）来协商
• 加密套件只包含：

TLS_<对称加密算法>-<哈希算法> 例：TLS_AES_128_GCM_SHA256

TLS 1.3 不再在加密套件里写明 密钥交换算法 和 认证算法。这些被移出加密套件，单独通过握手过程协商：

• 密钥交换：统一采用 (EC)DHE（临时密钥交换），算法在 SupportedGroups 扩展里协商，比如 X25519、secp256r1。
• 认证算法：在 signature_algorithms 扩展里协商，比如 RSA-PSS、ECDSA。

小结：HTTPS地址栏的小锁从何而来？

人们在“发明算法—发现缺陷—改进—新的发明”的循环中历经多轮迭代。从对称加密到非对称加密，再到对称非对称的结合，数字证书，最终发明了HTTPS。

所谓HTTPS，即是把明文的HTTP通过TLS层的加密而来。 访问HTTPS的网站，浏览器地址栏会出现一把小锁，这意味着：

• 你与此网站的通信都是加密的
• 此网站的数字证书通过了校验，被认可。没有中间人劫持。