TLS/SSL 协议 · 安全词条 | 点滴安全

TLS/SSL 协议

Transport Layer Security · Secure Sockets Layer · HTTPS

密码与身份安全词条4 章节

📅 创建于 2026/8/9🔄 最后更新 2026/8/26 · 1 天前👁️ 0 次浏览✏️ 5 次编辑来源

摘要

TLS（Transport Layer Security，传输层安全协议）是互联网应用最广泛的加密通信协议，为客户端与服务器之间的数据传输提供机密性、完整性和身份认证三重保障。它的前身是 Netscape 于 1994-1995 年开发的 SSL（Secure Sockets Layer），经历了 SSL 1.0（从未公开发布）、SSL 2.0（1995，多个严重漏洞）、SSL 3.0（1996）三代后，由 IETF 于 1999 年将其标准化并更名为 TLS 1.0。此后二十余年间历经 TLS 1.1（2006）、TLS 1.2（2008）、TLS 1.3（2018）三个主要版本，每次迭代都源于实战中发现的致命攻击。截至 2025 年，全球 Web 流量中超过 95% 通过 HTTPS（HTTP over TLS）加密传输（根据 Google Transparency Report 和 Firefox Telemetry 数据）。2014 年这一比例仅为约 40%。Let's Encrypt（2016 年正式上线）通过免费、自动化的证书签发使 HTTPS 从「成本负担」变为「默认配置」，是这一转变的关键推手。 TLS 的安全演进是「攻击驱动升级」的典型范例。SSL 3.0 的 POODLE 攻击（2014）导致其被彻底废弃；OpenSSL Heartbleed（2014，非 TLS 协议漏洞但暴露了协议实现的脆弱性）；RC4 在 TLS 中的 Bar-Mitzvah 攻击（2015）加速了流密码的淘汰；DROWN（2016）利用 SSLv2 攻击 TLS 会话；ROBOT（2018，Bleichenbacher 攻击的 20 年后重生）揭示了 RSA PKCS#1 v1.5 加密的持续风险。TLS 1.3（RFC 8446，2018 年 8 月）是首次以「安全设计优先」而非「向后兼容优先」为原则的大版本——移除所有已知不安全的算法和模式（RSA 密钥传输、CBC 模式、RC4、MD5/SHA-1 哈希），强制前向保密（PFS），将握手从 2-RTT 压缩至 1-RTT。

SSL 到 TLS：攻击驱动的版本演进

TLS 的发展史是一部攻防迭代史，每一次版本升级几乎都是应对某个被公开的攻击：

SSL 2.0（1995） 是最早公开部署的版本，存在根本性设计缺陷：握手不防降级（攻击者可强制连接退化为弱密码）、使用相同的 MAC 密钥应对加解密方向（缺少密钥方向分离）、无防截断保护。SSL 2.0 于 2011 年被 RFC 6176 正式宣布废弃，2016 年 DROWN 攻击利用了 SSLv2 的 40 位出口弱密码（Export-grade cipher）来攻击仍使用同一 RSA 密钥对的 TLS 服务器，影响约 33% 的 HTTPS 站点。

SSL 3.0（1996） 修复了 SSL 2.0 的多项弱点，但引入了 CBC 块模式填充——这正是 18 年后 POODLE 攻击的祸根。2014 年 10 月 Google 安全团队的 Bodo Möller、Thai Duong 和 Krzysztof Kotowicz 发布 POODLE（Padding Oracle On Downgraded Legacy Encryption），利用 SSL 3.0 的 CBC 填充不验证最后一字节以外的填充字节的设计缺陷，每字节只需 256 次请求即可恢复明文。SSL 3.0 随后被 RFC 7568 正式废弃。

TLS 1.0（1999） 和 TLS 1.1（2006） 是渐进式修补——引入显式初始化向量（IV）防 CBC 攻击、加入 BEAST 对抗填充（但未根治）。2020 年四大浏览器厂商（Chrome/Firefox/Safari/Edge）联合宣布于 2020 年底停止支持 TLS 1.0/1.1。PCI DSS 3.1（2015）已禁止支付卡环境使用 TLS 1.0。2021 年 3 月 IETF 正式废弃 TLS 1.0 和 1.1（RFC 8996）。

TLS 1.2（2008） 服役超过 15 年，引入了 AEAD 加密套件（AES-GCM）、支持 SHA-256 哈希替换 MD5/SHA-1 组合、提供更灵活的密码协商扩展。但 TLS 1.2 仍允许不安全的 RSA 密钥传输（非前向保密）、仍兼容 CBC 模式——正确实现难度大（Lucky13 计时攻击、Lucky Microseconds 等 padding oracle 变体持续涌现）。

TLS 1.3 握手：前向保密与 1-RTT 优化

TLS 1.3 握手协议是当代密码协议工程学的集大成之作，将安全性、性能和简洁性三个互斥目标统一在一个协议中。

完整握手（1-RTT）：

ClientHello：客户端发送支持的密码套件（仅 AEAD：TLS_AES_128_GCM_SHA256 等）、支持的密钥交换组（x25519/secp256r1）、随机 nonce 和可选的 ECDHE 公钥（客户端先行发送以节省半次往返）。
ServerHello：服务器从客户端选项中选择密码套件、密钥交换组，发送自己的随机 nonce 和 ECDHE 公钥。服务器至此已可派生出握手加密密钥——用 HKDF-Extract(shared_secret, "derived") 派生出主密钥，再用 HKDF-Expand-Label 派生出加密密钥和 MAC 密钥。
服务器紧接着发送 EncryptedExtensions（之前明文传输的 ServerHello 之后的扩展现在被加密，阻止协议指纹识别）、Certificate（服务器证书链）和 CertificateVerify（用服务器证书私钥对整个握手摘要签名）、Finished（用握手密钥 MAC 验证握手完整性）。
客户端验证服务器 Certificate + CertificateVerify，发送自己的 Finished。至此双方均持有相同的会话密钥。

前向保密（Forward Secrecy, PFS）：TLS 1.3 强制使用临时（Ephemeral）密钥交换（ECDHE），即使服务器长期私钥在未来泄露，过去的会话也无法被解密——因为每会话都使用独立的临时 ECDHE 密钥对，握手后双方即销毁私有的临时半密钥。TLS 1.2 中 RSA 密钥传输模式（使用服务器证书的公钥加密 Pre-Master Secret）不提供 PFS——持有服务器私钥的攻击者可解密所有历史会话。Snowden 文件（2013）披露大规模被动监控后，PFS 从「安全最佳实践」升级为「强制要求」。

0-RTT 与重放风险：TLS 1.3 的 0-RTT 模式允许客户端在首次握手时就夹带应用数据（如 HTTP GET 请求）——利用之前会话保存的 Pre-Shared Key（PSK）。这省去一个往返延迟但带来了重放攻击风险：攻击者截获 0-RTT 数据后可原样重放到服务器，导致非幂等操作被重复执行（如重复扣款）。TLS 1.3 将重放保护的决策权交给应用层——服务器在 ServerHello 中发送 early_data 扩展表示接受 0-RTT，并可选限定 0-RTT 可接受的 HTTP 方法（仅幂等的 GET/HEAD）。

TLS 扩展生态：SNI、ECH 与 ALPN

TLS 的扩展机制是其持续演进能力的核心——在不修改基础协议的前提下通过扩展字段引入新功能。

SNI（Server Name Indication，RFC 6066，2003）：允许客户端在 ClientHello 的 server_name 扩展中明文指明目标主机名，使服务器能够在同一 IP 地址上为多个域名（虚拟主机）提供不同的证书。SNI 是所有 CDN 和共享托管的基础——但 SNI 明文传输带来了隐私问题：中间观察者（ISP、防火墙）可知悉用户正在访问的具体域名。Cloudflare Radar 数据显示，约 20% 的国家级网络审查依赖 SNI 过滤。

ECH（Encrypted ClientHello，原名 ESNI，RFC 最新草案）：将 ClientHello 中的敏感字段（包括 SNI）加密。客户端使用从 DNS HTTPS 记录获取的服务端公钥加密内层 ClientHello，外层的明文 ClientHello 使用一个通用的「面纱」域名（cover name）。只有目标服务器能解密内层 ClientHello。Cloudflare 于 2023 年 9 月默认启用 ECH 支持。ECH 使 SNI 过滤和被动流量分类不再有效——这是一个重大隐私进步，但也对网络管理的透明性带来新挑战。

ALPN（Application-Layer Protocol Negotiation，RFC 7301）：允许客户端在 ClientHello 中列出支持的应用协议（如 h2/http1.1），服务器选择后告知客户端。HTTP/2 和 HTTP/3 的协商依赖 ALPN。h2（HTTP/2 over TLS）和 h3（HTTP/3）均需通过 ALPN 指示——没有 ALPN 就没有现代 HTTP。

OCSP Stapling（RFC 6066/6961）：服务器在 TLS 握手时将预先从 CA 获取的 OCSP 响应（证书撤销状态）附加发送，避免客户端独立发起 OCSP 请求带来的隐私泄露和延迟。Must-Staple 证书（RFC 7633）要求服务器必须提供 OCSP Staple，否则浏览器拒绝连接。

Certificate Compression（RFC 8879）：TLS 证书链（尤其包含后量子证书时）可能达数十 KB，证书压缩扩展使用 zlib/brotli 压缩证书链减少握手体积——这对后量子证书（ML-DSA 签名约 2.4-7.9 KB）至关重要。

TLS/SSL 协议

SSL 到 TLS：攻击驱动的版本演进

TLS 1.3 握手：前向保密与 1-RTT 优化

TLS 扩展生态：SNI、ECH 与 ALPN

声明与维护记录

参考资料