网络安全基础：对称加密、非对称加密与 TLS
每天你访问的网站都挂着 https://，浏览器地址栏一把小锁。但如果有人问你：“这把锁到底锁住了什么？数据是怎么加密的？为什么你能确信对面真的是银行，而不是冒充的？”——很多人会卡壳，只能含糊地说一句"反正 HTTPS 很安全"。
问题出在学习顺序上。多数人是先记住"对称加密快、非对称加密慢"这类结论，却没先搞懂这几种密码学工具各自在解决什么具体问题、TLS 握手时它们是怎么一步步配合起来协商出一把密钥的。结论记了一堆，却串不成一条线。
所以这一篇我们换个顺序：先把每件工具的机制讲透——对称加密怎么用一把钥匙、非对称加密怎么用一对钥匙、摘要和签名各自校验什么——再看 TLS 握手是怎样把它们按顺序拼装起来，最后才谈这些设计背后的取舍。 你会发现，安全不是神秘学，它只是在一层层、有条理地解决具体问题。
一、安全到底要解决哪几件事
在认识工具之前，先把目标钉死。数据在公网上传输，面对的威胁可以归成三类，对应三个安全目标：
- 保密性（Confidentiality）：数据在路上不能被偷看。对策——加密。
- 完整性（Integrity）：数据不能被悄悄篡改。对策——摘要 / 消息认证码。
- 身份认证（Authentication）：你得确认对面是谁，不能被冒充。对策——数字签名 / 证书。
后面所有密码学工具，本质都是在分别攻克"保密、完整、认证"这三件事。始终拿这三个目标去对照，每个工具该放在哪个位置就清楚了。
二、对称加密的机制：一把钥匙锁两头
对称加密最直观：加密和解密用同一把密钥。发送方用密钥 K 把明文 加密，接收方用同一把 K 把密文 解密。常见算法是 AES。
它的机制特点带来两个性质：
- 快。对称算法基于位运算和查表，现代 CPU 还有
AES-NI硬件指令加速，吞吐能到每秒数 GB。所以它适合保护大量数据。 - 致命前提：通信双方必须先安全地拥有同一把钥匙。
第二点就是对称加密自己解决不了的死结：钥匙怎么送过去？你不能把钥匙明文发给对方——公网上谁都能截获，截获了钥匙，再快的加密也形同虚设。
对称加密回答了"如何高效保护数据"，但回答不了"如何在不安全的网络里先把钥匙安全地交给对方"。这个缺口，正是非对称加密要补的。
三、非对称加密的机制：一对钥匙，分工不同
非对称加密用一对数学上关联的密钥：公钥可以公开给任何人，私钥自己严密保管。代表算法是 RSA 和基于椭圆曲线的 ECC。这对钥匙有个奇妙性质——用其中一把加密，只能用另一把解密。这就衍生出两种用法：
用法一·加密传输（公钥加密，私钥解密）：
别人想给你发机密，用你的公钥加密。密文只有持有私钥的你能解开。即使公钥满天飞、密文被截获，没有私钥也解不了。这恰好解决了对称加密的死结——别人可以用我的公钥把"对称密钥"加密了发给我。
用法二·数字签名（私钥签名，公钥验证）：
你用自己的私钥对内容签名，别人用你的公钥验证。验证通过就证明"这内容确实出自私钥持有者，且没被改过"。因为只有你有私钥，别人伪造不出能通过你公钥验证的签名。
代价是：非对称运算涉及大数模幂等复杂数学，比对称加密慢几个数量级。所以它不适合全程加密大量业务数据。
非对称加密专攻"在不安全环境里建立初始信任"——要么安全地交换对称密钥，要么证明身份。它慢，所以只在握手的关键节点用，不扛大流量。
到这里，一个组合思路已经呼之欲出：用非对称加密在握手阶段安全地协商出一把对称密钥，之后用这把对称密钥高速加密业务数据。 取两者之长，这正是 TLS 的核心骨架。
四、摘要与签名的机制：怎么保证"没被改"和"是谁发的"
光有加密还不够。哈希摘要和签名负责完整性与认证。
摘要（Hash）：摘要算法（如 SHA-256）把任意长度数据压成一段固定长度的"指纹"。它有两个关键性质：输入只要变一个比特，输出指纹就面目全非（雪崩效应）；且不可逆，没法从指纹反推原文。所以接收方重新算一遍指纹，和发来的对比，就能判断内容有没有被动过。
但单纯摘要防不住"中间人连内容带指纹一起替换"。于是有两种加固：
- HMAC（消息认证码）：把摘要和一把共享密钥绑在一起算，攻击者没有密钥就伪造不出正确的 HMAC。它同时保证完整性和"来自持有密钥的一方"。
- 数字签名：用私钥对摘要签名。它比 HMAC 更进一步——不需要预先共享密钥，靠公钥就能验证，且能向第三方证明来源（不可否认性）。
摘要验"内容有没有变"；HMAC 在摘要上加共享密钥，验"变没变 + 来自持密钥方"；数字签名用私钥签摘要，验"变没变 + 确实是私钥持有者发的"，且别人无法抵赖。
五、证书：公钥到底是谁的
非对称加密还剩最后一个漏洞：你拿到一把公钥，凭什么相信它是银行的，而不是中间人塞给你的假公钥？ 如果信错了公钥，中间人就能冒充银行。
解决办法是引入可信第三方——CA（证书颁发机构）。流程是：银行把自己的公钥和域名等信息提交给 CA，CA 核实身份后，用 CA 自己的私钥对这些信息签名，生成一张数字证书。
浏览器/操作系统里预装了各大 CA 的公钥（信任根）。当你拿到银行的证书，就用预装的 CA 公钥去验证证书上的签名：
- 验证通过 → 证明"这把公钥确实属于这个域名，且由可信 CA 背书"；
- 验证失败 / CA 不被信任 / 域名对不上 / 证书过期 → 浏览器弹出那个刺眼的安全警告。
证书的本质是"CA 用自己的信誉（私钥签名）为某把公钥和某个域名的绑定关系做担保"。它不是形式主义，而是整个 HTTPS 信任链的根。验证证书，就是在验证"对面是不是它声称的那个身份"。
六、TLS 握手：把所有工具按顺序拼起来
现在把上面所有零件组装。TLS 握手的目标，是在不安全的网络上协商出一把双方共享的对称密钥，同时确认服务端身份。以经典的 TLS 1.2 握手为例：
逐步拆解这条链：
- ClientHello：客户端告诉服务端"我支持哪些加密套件"，并附一个随机数。
- ServerHello + Certificate：服务端选定一套算法，回自己的随机数，并把证书发来——证书里装着服务端公钥和 CA 的签名。
- 验证身份：客户端用本地预装的 CA 公钥验证证书签名。这一步用到了第五节的证书机制和第四节的签名验证，确认对面身份无误，并安全地拿到了服务端公钥。
- 协商密钥：客户端生成密钥材料，用服务端公钥加密后发过去（用到第三节的非对称加密）。只有服务端的私钥能解开。双方再结合两个随机数，各自算出完全相同的对称会话密钥。
- 切换到对称加密：双方发
Finished互相验证握手没被篡改，此后所有业务数据都用刚协商出的对称密钥高速加密（用到第二节的对称加密），完整性则由 HMAC 保护。
看清这条链，你就明白 TLS 的精髓：非对称加密负责"安全地把对称密钥协商出来"这件慢但关键的事，对称加密负责之后"高速保护海量数据"这件需要快的事，证书负责认证，HMAC 负责完整性——每件工具都被放在它最擅长的位置。
TLS 没有发明任何新的密码学魔法，它的强大恰恰来自"编排"：把对称、非对称、摘要、签名、证书五件成熟工具，按"先认证、再协商密钥、后高速传输"的顺序拼到了正确的位置上。
补充一句演进：TLS 1.3 把握手从两个往返压缩到一个往返（甚至 0-RTT 恢复），并强制使用支持前向保密的密钥交换（如 ECDHE）——即便服务端私钥日后泄露，也无法解密之前抓到的历史流量。这背后仍是同一套工具，只是编排更精巧、更安全。
七、回到设计：为什么安全总是在取舍
机制清楚后，再看设计动机就顺了。为什么不一律用"最强加密、最严校验"？因为安全永远在和成本、性能、兼容性博弈：
- 更长的密钥、更复杂的握手 → 更高的 CPU 开销和延迟（这正是当年很多服务嫌 HTTPS"贵"而不愿全站启用的原因，直到硬件加速和 TLS 1.3 才扭转）；
- 更严格的证书校验、双向认证（mTLS）→ 更高的运维复杂度（证书签发、轮换、吊销）；
- 兼容老客户端 → 可能被迫保留较弱的算法套件，带来降级攻击风险。
现实中没有"绝对安全"，只有"在性能、兼容性、运维成本和可接受风险之间的平衡点"。理解这一点，你才能看懂 TLS 版本演进、证书部署策略、网关层 TLS 终止这些工程决策为什么是现在这个样子。
八、和后端/SRE 实践的联系
这套基础不是考试名词，它天天出现在你的工作里：
- 网关 TLS 终止：很多架构在负载均衡/网关层就把 TLS 解开（终止），内网再走明文或更轻的加密。理解握手在哪一层发生，你才知道抓包时哪里能看到明文、证书该装在哪。
- 证书到期告警：线上事故里"证书过期导致全站不可访问"是经典惨案。懂了证书是 CA 的签名背书、有有效期，你就知道为什么必须监控并自动轮换。
- mTLS 与服务网格：微服务之间用双向 TLS 互认身份，靠的就是第五、六节那套证书+签名机制，只是双方都要验对方证书。
- 抓包看握手：用 Wireshark 能清楚看到
ClientHello/ServerHello/Certificate，但业务数据已被对称加密——这正好印证了握手明文、数据密文的机制分工。
学习这一部分最容易踩的坑
1. 只背"对称快、非对称慢"，不知道为什么要组合
这句话是结论，不是理解。关键在于：非对称解决"密钥怎么安全送达和身份认证"，对称解决"大数据怎么高速加密"，TLS 把两者按顺序拼起来。脱离了"组合"，这两句话就是死知识。
2. 以为 HTTPS = 加密就够了
HTTPS 真正难也真正值钱的部分是身份认证——证书在证明"对面确实是这个域名"。只加密不认证，照样会把数据加密后乒乒乓乓发给一个中间人。锁的意义一半在保密，一半在认证。
3. 把摘要、HMAC、签名混为一谈
摘要只验内容是否变；HMAC 在摘要上加共享密钥，能验来源（持密钥方）；签名用私钥，能向第三方证明来源且不可否认。三者能力递增，用错场景就会留下漏洞。
4. 忽视证书链和信任根
证书不是单张孤立的纸，而是一条链：服务端证书由中间 CA 签，中间 CA 由根 CA 签，根 CA 预装在系统里。线上"证书校验失败"很多时候是中间证书没配全导致链断了，而不是证书本身有问题。
总结
这一篇我们坚持先讲机制、再谈设计，核心要带走的是密码学工具如何各司其职、又如何被 TLS 编排到一起：
- 安全围绕三件事——保密（加密）、完整（摘要/HMAC）、认证（签名/证书）；
- 对称加密快但难解决密钥分发，非对称加密慢但能安全交换密钥并认证身份，二者天生互补；
- 摘要验内容、HMAC 验来源与完整、签名用私钥提供不可否认的身份证明；
- 证书是 CA 用私钥为"公钥与域名的绑定"做的信誉担保，是 HTTPS 信任链的根；
- TLS 握手把这五件工具按"认证→协商对称密钥→高速对称传输"的顺序拼装，强大之处在编排而非新算法；
- 安全设计永远在性能、兼容、运维与风险之间取舍，没有免费的绝对安全。
当你能在脑子里默画出那条 ClientHello → 验证书 → 用公钥送密钥材料 → 切换对称加密 的握手链，并说清每一步用到了哪件工具、解决哪个安全目标，这部分就真正属于你了。
参考资源：
- 《图解 HTTP》与《图解 TLS/SSL》
- 《密码学原理与实践》（Cryptography: Theory and Practice）
- RFC 8446 - TLS 1.3
- Cloudflare - How TLS works