第 1 篇TLS 安全的基础——你必须知道的密码学常识标签#网络安全#密码学#TLS#HTTPS为什么你的网站需要 HTTPSChrome 对所有 HTTP 网站强制标注「不安全」已经好几年TLS 1.0/1.1 早已被所有主流浏览器禁用2026 年 TLS 1.3 是绝对的主流——Cloudflare、Akamai 的数据显示 TLS 1.3 占比超过 60%很多网站甚至超过 90%。但真正理解 HTTPS 在保护什么的人并不多。这一篇我们聊最底层的事HTTPS 的密码学基石。不写数学公式只讲每个开发者都必须理解的 6 个核心概念。密码学的六大构件TLS 本身并不神秘——它只是把一些基础的密码学构件巧妙地组合在一起。理解这些构件你就理解了 TLS 的一半。1. 散列函数Hash——数据的「指纹」想象一个魔法盒子无论你丢进去的是 1 KB 的文本还是 10 GB 的视频它都吐出一个固定长度的字符串——这就是散列值digest。密码学散列有三个铁律✅相同的输入永远产生相同的输出确定性✅不同的输入几乎不可能产生相同的输出抗碰撞✅不可逆——你无法从散列值反推原文抗原像冷知识因为「生日悖论」这个概率论现象散列函数的实际强度大约只有输出长度的一半。256 位的 SHA-256抗碰撞强度等价于 128 位安全。MD5 和 SHA-1 已经死了2017 年 Google 用 SHAttered 攻击公开了完整的 SHA-1 碰撞任何还在用 SHA-1 做数字签名或证书的系统都该立刻升级。常用算法SHA-256 / SHA-384 / SHA-3。2. 消息认证码MAC / HMAC——带钥匙的指纹散列有个致命弱点它防篡改的前提是散列值和数据分开传输。如果攻击者同时改数据 改散列你就完全察觉不到。HMAC 的解法在计算散列时混入一个只有你和服务器知道的密钥。没有密钥攻击者就算改了数据也伪造不出合法的 MAC 值。方案能否检测篡改前提单纯散列❌ 不能假设散列能被独立验证HMAC✅ 能双方共享密钥血泪教训加密 ≠ 完整性。加密只能让 Mallory「看不懂」消息但她完全可以「盲改」密文诱使接收方解密出她想要的内容。所以加密和 MAC 必须一起用——这就是后面要讲的 AEAD。3. 分组密码——固定大小的加密盒子分组密码一次加密一整块数据通常是 128 位 16 字节。AES是绝对的业界标准支持 128/192/256 位密钥。但分组密码直接拿来用有两个坑数据不够 16 字节怎么办需要填充paddingTLS 的做法是在最后一字节写上「填充长度 N」倒数 N 字节都填上值 N。确定性陷阱相同的明文块总是产生相同的密文块——攻击者一眼就能看出明文的模式这就是著名的「企鹅图」漏洞。解决第二个坑要用「分组密码模式」模式安全性说明ECB电码本❌ 别用一块一加密相同明文 → 相同密文CBC密码块链接⚠️ TLS 1.0~1.2 主力用前一块密文做「扰动」需要随机 IVGCM伽罗瓦计数器✅ 现代首选同时提供加密 完整性性能也好ChaCha20-Poly1305✅ 移动端首选流密码 认证软件实现快冷知识现代 TLS 默认用的AEAD已验证加密模式——GCM 或 ChaCha20-Poly1305——把加密和完整性验证「打包」成一个原语彻底消除了「先加密再 MAC」还是「先 MAC 再加密」的工程歧义。ChaCha20-Poly1305 在没有硬件 AES 加速的移动设备上特别受欢迎。4. 对称加密 vs 非对称加密这是理解 TLS「为什么这么设计」的关键。对称加密非对称加密密钥数量1 把双方共享一对公钥 私钥速度⚡ 极快GB/s 级 慢 100~1000 倍典型算法AES-GCM、ChaCha20RSA、ECDSA、ECDHE适合场景加密大量数据身份验证、密钥协商、签名对称加密的问题是密钥管理N 个人两两通信需要 N×(N-1)/2 把密钥——1000 人就接近 50 万把根本管不过来。TLS 的天才之处在于「混搭」用非对称加密ECDHE安全地协商出一个临时的对称密钥后续所有数据都用对称加密AES-GCM 或 ChaCha20-Poly1305高速传输。两全其美。5. 数字签名——电子世界的「手写签名」HMAC 依赖「双方事先共享密钥」但第一次通信怎么建立信任答案就是数字签名。签名方: digest SHA-256(消息) signature 用私钥加密(digest) 验证方: digest_claimed 用公钥解密(signature) digest_actual SHA-256(消息) 验证通过 ⟺ digest_claimed digest_actual证书里 CA 给你盖的章、代码签名里软件作者盖的章本质都是这个流程。冷知识RSA 既能加密也能签名但 ECDSA 只能签名——它依赖其他机制完成加密。如今越来越多的证书改用ECDSA而非 RSA因为 ECDSA 签名短64 字节 vs 256 字节、验签快特别适合移动端。6. 随机数——安全性的命脉TLS 的所有安全性归根结底都依赖随机数的质量。因为密钥本质上就是一个「非常长的随机数」。计算机是很笨的你让它rand()它输出的「随机数」对密码学来说根本不够随机。真正的随机性只能从物理世界采集键盘按键间隔鼠标移动轨迹硬盘寻道抖动麦克风 / 摄像头噪声这些统称为熵entropy。系统收集熵后用PRNG伪随机数生成器扩展出大量「看似随机、实际可重现」的数用于密码学的 PRNG 还要满足不可预测性。真实翻车案例2006 年 Debian OpenSSL开发者清理代码时误删了随机数种子调用整个发行版的 SSH 密钥空间从 2^128 缩小到 2^15攻击者几小时就能穷举。嵌入式设备熵不足路由器、摄像头启动后没有键盘鼠标可用熵极少如果不妥善处理生成的密钥强度会大打折扣。威胁模型你的对手是谁不理解攻击者能做什么就不知道 TLS 在保护你什么。被动攻击——「窃听者 Eve」能力只能看不能改典型场景公共 Wi-Fi 嗅探、运营商流量镜像、政府的「上游监听」2013 斯诺登事件揭露 GCHQ 曾记录英国几乎全部互联网流量TLS 的作用让 Eve 看到的只有密文关键洞察TLS 不能隐藏你的 IP 和域名SNI 曾经是明文的ECHEncrypted Client Hello现在能解决但它能让密文在 10 年后仍是密文——前提是用了前向保密。主动攻击——「捣乱者 Mallory」能力可以修改、丢弃、注入消息典型场景中间人攻击MITM、DNS 劫持、BGP 路由劫持、ARP 欺骗TLS 的作用通过身份验证证书完整性MAC/AEAD让 Mallory 无法伪装主动攻击威力大但难规模化——每个目标都要单独投入。所以它主要用于高价值目标如 NSA 的QuantumInsert项目对特定浏览器发起漏洞利用。攻击类型难度规模TLS 防御手段被动窃听低极大加密 前向保密主动 MITM高较小证书 证书透明度 HSTS给开发者的三条建议① 不要自己设计加密协议密码学是一门专业到反直觉的学科。「稍微改一下 RSA 的填充方式」「在握手里加一个 nonce」——听起来无害几乎必然会引入致命漏洞。规则用标准协议TLS 1.2/1.3、用成熟库OpenSSL、BoringSSL、Go crypto/tls、Python cryptography绝不直接调算法。② 启用前向保密Forward SecrecyRSA 密钥交换有一个致命缺陷服务器私钥一旦泄露攻击者可以解密所有历史流量——只要他当时记下了密文。前向保密通过「每会话一个临时密钥」解决这个常用算法是ECDHE椭圆曲线 Diffie-Hellman 临时密钥。TLS 1.3 已经强制前向保密——任何静态密钥交换都被删除。真实教训斯诺登使用的 Lavabit 邮件服务不支持前向保密FBI 拿到服务器 RSA 私钥后直接解密了他所有历史邮件。这个事故直接推动了整个行业向前向保密迁移。配置检查# Nginx 推荐配置已启用前向保密 TLS 1.3 ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305; ssl_prefer_server_ciphers on;③ 128 位安全是底线「位数」就是攻击者要执行的操作次数。128 位意味着 2^128 次操作——目前的计算机宇宙寿命内也跑不完。强度对称密钥RSA / DH椭圆曲线适用场景80 位AES-801024160❌ 已淘汰112 位AES-1282048224✅ 当前最低推荐128 位AES-1283072256✅✅ 大多数场景足够256 位AES-25615360512长期保密、量子防御大多数场景128 位AES-128、EC-256、RSA-3072足够需要 10~30 年保密上 256 位担心未来量子计算机威胁关注 ML-KEMKyber等后量子算法浏览器和主流 CA 已经在灰度部署。延伸阅读Bulletproof TLS and PKI — Ivan Ristić业界公认的 TLS 圣经NIST SP 800-57 — 密钥管理的「圣经」keylength.com — 各家推荐密钥长度的对照表《Understanding Cryptography》 — Christof Paar Jan Pelzl密码学入门首选 第 1 篇：TLS 安全的基础——你必须知道的密码学常识
第 1 篇TLS 安全的基础——你必须知道的密码学常识标签#网络安全#密码学#TLS#HTTPS为什么你的网站需要 HTTPSChrome 对所有 HTTP 网站强制标注「不安全」已经好几年TLS 1.0/1.1 早已被所有主流浏览器禁用2026 年 TLS 1.3 是绝对的主流——Cloudflare、Akamai 的数据显示 TLS 1.3 占比超过 60%很多网站甚至超过 90%。但真正理解 HTTPS 在保护什么的人并不多。这一篇我们聊最底层的事HTTPS 的密码学基石。不写数学公式只讲每个开发者都必须理解的 6 个核心概念。密码学的六大构件TLS 本身并不神秘——它只是把一些基础的密码学构件巧妙地组合在一起。理解这些构件你就理解了 TLS 的一半。1. 散列函数Hash——数据的「指纹」想象一个魔法盒子无论你丢进去的是 1 KB 的文本还是 10 GB 的视频它都吐出一个固定长度的字符串——这就是散列值digest。密码学散列有三个铁律✅相同的输入永远产生相同的输出确定性✅不同的输入几乎不可能产生相同的输出抗碰撞✅不可逆——你无法从散列值反推原文抗原像冷知识因为「生日悖论」这个概率论现象散列函数的实际强度大约只有输出长度的一半。256 位的 SHA-256抗碰撞强度等价于 128 位安全。MD5 和 SHA-1 已经死了2017 年 Google 用 SHAttered 攻击公开了完整的 SHA-1 碰撞任何还在用 SHA-1 做数字签名或证书的系统都该立刻升级。常用算法SHA-256 / SHA-384 / SHA-3。2. 消息认证码MAC / HMAC——带钥匙的指纹散列有个致命弱点它防篡改的前提是散列值和数据分开传输。如果攻击者同时改数据 改散列你就完全察觉不到。HMAC 的解法在计算散列时混入一个只有你和服务器知道的密钥。没有密钥攻击者就算改了数据也伪造不出合法的 MAC 值。方案能否检测篡改前提单纯散列❌ 不能假设散列能被独立验证HMAC✅ 能双方共享密钥血泪教训加密 ≠ 完整性。加密只能让 Mallory「看不懂」消息但她完全可以「盲改」密文诱使接收方解密出她想要的内容。所以加密和 MAC 必须一起用——这就是后面要讲的 AEAD。3. 分组密码——固定大小的加密盒子分组密码一次加密一整块数据通常是 128 位 16 字节。AES是绝对的业界标准支持 128/192/256 位密钥。但分组密码直接拿来用有两个坑数据不够 16 字节怎么办需要填充paddingTLS 的做法是在最后一字节写上「填充长度 N」倒数 N 字节都填上值 N。确定性陷阱相同的明文块总是产生相同的密文块——攻击者一眼就能看出明文的模式这就是著名的「企鹅图」漏洞。解决第二个坑要用「分组密码模式」模式安全性说明ECB电码本❌ 别用一块一加密相同明文 → 相同密文CBC密码块链接⚠️ TLS 1.0~1.2 主力用前一块密文做「扰动」需要随机 IVGCM伽罗瓦计数器✅ 现代首选同时提供加密 完整性性能也好ChaCha20-Poly1305✅ 移动端首选流密码 认证软件实现快冷知识现代 TLS 默认用的AEAD已验证加密模式——GCM 或 ChaCha20-Poly1305——把加密和完整性验证「打包」成一个原语彻底消除了「先加密再 MAC」还是「先 MAC 再加密」的工程歧义。ChaCha20-Poly1305 在没有硬件 AES 加速的移动设备上特别受欢迎。4. 对称加密 vs 非对称加密这是理解 TLS「为什么这么设计」的关键。对称加密非对称加密密钥数量1 把双方共享一对公钥 私钥速度⚡ 极快GB/s 级 慢 100~1000 倍典型算法AES-GCM、ChaCha20RSA、ECDSA、ECDHE适合场景加密大量数据身份验证、密钥协商、签名对称加密的问题是密钥管理N 个人两两通信需要 N×(N-1)/2 把密钥——1000 人就接近 50 万把根本管不过来。TLS 的天才之处在于「混搭」用非对称加密ECDHE安全地协商出一个临时的对称密钥后续所有数据都用对称加密AES-GCM 或 ChaCha20-Poly1305高速传输。两全其美。5. 数字签名——电子世界的「手写签名」HMAC 依赖「双方事先共享密钥」但第一次通信怎么建立信任答案就是数字签名。签名方: digest SHA-256(消息) signature 用私钥加密(digest) 验证方: digest_claimed 用公钥解密(signature) digest_actual SHA-256(消息) 验证通过 ⟺ digest_claimed digest_actual证书里 CA 给你盖的章、代码签名里软件作者盖的章本质都是这个流程。冷知识RSA 既能加密也能签名但 ECDSA 只能签名——它依赖其他机制完成加密。如今越来越多的证书改用ECDSA而非 RSA因为 ECDSA 签名短64 字节 vs 256 字节、验签快特别适合移动端。6. 随机数——安全性的命脉TLS 的所有安全性归根结底都依赖随机数的质量。因为密钥本质上就是一个「非常长的随机数」。计算机是很笨的你让它rand()它输出的「随机数」对密码学来说根本不够随机。真正的随机性只能从物理世界采集键盘按键间隔鼠标移动轨迹硬盘寻道抖动麦克风 / 摄像头噪声这些统称为熵entropy。系统收集熵后用PRNG伪随机数生成器扩展出大量「看似随机、实际可重现」的数用于密码学的 PRNG 还要满足不可预测性。真实翻车案例2006 年 Debian OpenSSL开发者清理代码时误删了随机数种子调用整个发行版的 SSH 密钥空间从 2^128 缩小到 2^15攻击者几小时就能穷举。嵌入式设备熵不足路由器、摄像头启动后没有键盘鼠标可用熵极少如果不妥善处理生成的密钥强度会大打折扣。威胁模型你的对手是谁不理解攻击者能做什么就不知道 TLS 在保护你什么。被动攻击——「窃听者 Eve」能力只能看不能改典型场景公共 Wi-Fi 嗅探、运营商流量镜像、政府的「上游监听」2013 斯诺登事件揭露 GCHQ 曾记录英国几乎全部互联网流量TLS 的作用让 Eve 看到的只有密文关键洞察TLS 不能隐藏你的 IP 和域名SNI 曾经是明文的ECHEncrypted Client Hello现在能解决但它能让密文在 10 年后仍是密文——前提是用了前向保密。主动攻击——「捣乱者 Mallory」能力可以修改、丢弃、注入消息典型场景中间人攻击MITM、DNS 劫持、BGP 路由劫持、ARP 欺骗TLS 的作用通过身份验证证书完整性MAC/AEAD让 Mallory 无法伪装主动攻击威力大但难规模化——每个目标都要单独投入。所以它主要用于高价值目标如 NSA 的QuantumInsert项目对特定浏览器发起漏洞利用。攻击类型难度规模TLS 防御手段被动窃听低极大加密 前向保密主动 MITM高较小证书 证书透明度 HSTS给开发者的三条建议① 不要自己设计加密协议密码学是一门专业到反直觉的学科。「稍微改一下 RSA 的填充方式」「在握手里加一个 nonce」——听起来无害几乎必然会引入致命漏洞。规则用标准协议TLS 1.2/1.3、用成熟库OpenSSL、BoringSSL、Go crypto/tls、Python cryptography绝不直接调算法。② 启用前向保密Forward SecrecyRSA 密钥交换有一个致命缺陷服务器私钥一旦泄露攻击者可以解密所有历史流量——只要他当时记下了密文。前向保密通过「每会话一个临时密钥」解决这个常用算法是ECDHE椭圆曲线 Diffie-Hellman 临时密钥。TLS 1.3 已经强制前向保密——任何静态密钥交换都被删除。真实教训斯诺登使用的 Lavabit 邮件服务不支持前向保密FBI 拿到服务器 RSA 私钥后直接解密了他所有历史邮件。这个事故直接推动了整个行业向前向保密迁移。配置检查# Nginx 推荐配置已启用前向保密 TLS 1.3 ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305; ssl_prefer_server_ciphers on;③ 128 位安全是底线「位数」就是攻击者要执行的操作次数。128 位意味着 2^128 次操作——目前的计算机宇宙寿命内也跑不完。强度对称密钥RSA / DH椭圆曲线适用场景80 位AES-801024160❌ 已淘汰112 位AES-1282048224✅ 当前最低推荐128 位AES-1283072256✅✅ 大多数场景足够256 位AES-25615360512长期保密、量子防御大多数场景128 位AES-128、EC-256、RSA-3072足够需要 10~30 年保密上 256 位担心未来量子计算机威胁关注 ML-KEMKyber等后量子算法浏览器和主流 CA 已经在灰度部署。延伸阅读Bulletproof TLS and PKI — Ivan Ristić业界公认的 TLS 圣经NIST SP 800-57 — 密钥管理的「圣经」keylength.com — 各家推荐密钥长度的对照表《Understanding Cryptography》 — Christof Paar Jan Pelzl密码学入门首选