SSL/TLS

本文约需 2 分钟阅读

SSL/TLS (Secure Sockets Layer / Transport Layer Security) 是一种加密互联网通信的协议。它对 Web 浏览器与服务器之间的数据进行加密，防止第三方窃听和篡改。TLS 是 SSL 的后继协议，但习惯上仍统称为 SSL/TLS。 HTTPS 中的「 S 」指的就是这项技术。

历史背景

SSL 由 Netscape Communications 于 1994 年开发。在 SSL 2.0 (1995 年) 和 SSL 3.0 (1996 年) 之后， IETF 于 1999 年将 TLS 1.0 标准化。 SSL 3.0 被发现存在 POODLE 攻击等严重漏洞，现已禁止使用。 TLS 1.2 (2008 年) 长期作为主流，但 2018 年制定了 TLS 1.3，实现了握手加速与安全性增强。由于 Google 在 2014 年宣布将 HTTPS 纳入排名因素， Web 网站的 HTTPS 化迅速推进，截至 2025 年， Web 流量的 95% 以上都已通过 HTTPS 加密。主流浏览器已完全终止对 TLS 1.0 和 1.1 的支持，迁移到 TLS 1.3 已成为标准。

SSL/TLS 的工作原理

在 TLS 握手中，服务器首先出示数字证书以证明其身份。接着，客户端与服务器安全地交换共享加密密钥，并使用对称密码对之后的通信进行加密。在 TLS 1.3 中，握手被简化为 1-RTT (一次往返)，连接速度与安全性均得到提升。

实际使用的组合在何处被决定

通信是否被加密，并不由服务器声称支持的版本一览来决定。每次连接时，实际使用的组合都是从双方都能使用的方式中选出的，因此结果取决于服务器允许什么与前来连接的一方要求什么之间的重叠。即使已经增加了对较新方式的支持，只要对较旧方式的许可仍然保留，与要求使用较旧方式的一方通信时就仍会使用它。这份许可一览具有容易朝增多方向变动的性质。当出现某一方无法连接的情况时，作为处置手段会追加条目，而追加的理由往往没有被记录就一直保留下来。日后想要移除时，就需要知道它为何存在的信息，而这一点并未写在配置本身之中。结果，一览的复查与其说是技术性作业，不如说是寻找判断依据的作业。另一个前提是，被允许的组合必须从外侧连接来加以确认。作为配置写下的内容，与实际接受的组合并不总是一致。原因可能是未写明的条目适用了默认值，可能是路径上负责中转的设备持有另一套设置，也可能是多个受理入口中只有一部分被设成了不同的内容。在受理入口有多个的构成中，无法保证它们同时处于相同状态，因此确认需要逐个受理入口进行。可见这一领域的管理并非确定一个要使用的版本就算完成，而是作为一项持续的作业存在：定期从外侧确认被允许的组合一览，以及该一览在所有受理入口是否相同。

TLS 握手流程

实务中的注意事项

SSL/TLS 保护密码传输时的通信路径。在登录表单中输入密码时，请务必确认使用的是 HTTPS 连接。实务中常见的陷阱是忽视证书的有效期到期。随着 Let's Encrypt 的普及，已可以免费获取证书，但若疏于设置自动续期，网站会突然显示为「不安全」。此外，仍启用旧版 TLS (1.0 、 1.1) 的服务器存在漏洞风险。无论设置多么强大的密码，在未加密的通信中都有被拦截的风险，因此养成确认浏览器地址栏中显示锁形图标的习惯非常重要。