传输层安全协议

定义

传输层安全协议是一种运行在可靠传输协议之上的密码学协议，作用是为两个对等端点之间的通信提供安全信道。按照规范给出的定义，该信道需要同时满足三项性质：服务器一端始终被认证、客户端一端可选择认证；信道上传输的数据只对通信双方可见；数据被改动后能够被察觉。这三项性质分别对应身份认证、机密性与完整性。

该协议由两个主要部分组成：握手协议负责协商密码参数、认证通信双方并生成共享密钥；记录协议则使用握手得出的密钥，把上层数据切分成记录逐条保护。协议与具体应用层协议相互独立，上层协议可以透明地运行在其之上。微软的技术文档把它的位置描述为介于应用协议层与 TCP/IP 层之间，因此可以同时服务多种应用层协议。

原理

握手阶段首先由客户端发送 ClientHello，其中携带随机数、支持的协议版本、候选密码套件、密钥交换的公开参数以及支持的签名算法；服务器以 ServerHello 选定参数并给出自己的密钥交换参数。TLS 1.3 支持三种密钥建立方式：(EC)DHE、仅 PSK，以及 PSK 与 (EC)DHE 组合，其中后一种可在共享密钥之外额外获得前向保密性。

身份认证通常基于 X.509 证书完成。服务器在 Certificate 消息中发送证书链，随后用与证书公钥对应的私钥对握手记录做签名并放入 CertificateVerify，客户端据此确认对端确实掌握该私钥。握手以 Finished 消息收尾，它是对整段握手记录计算的校验值，用于密钥确认并绑定双方身份。

密钥派生在 TLS 1.3 中使用 HKDF。输入的秘密材料依次为 PSK 与 (EC)DHE 共享秘密，逐级提取出早期秘密、握手秘密与主秘密，再派生出客户端与服务端各自的握手流量密钥和应用流量密钥。可以概括为：

$\text{PSK} \rightarrow \text{Early Secret} \xrightarrow{(EC)DHE} \text{Handshake Secret} \rightarrow \text{Master Secret}$

记录层把待发送数据切成不超过 $2^{14}$ 字节的片段，用 AEAD 算法加密并附上认证标签；每条记录的随机数由 64 位序列号与该连接的静态初始向量异或得到。解密失败时统一返回同一个告警，避免通过错误差异泄露信息。其流程可简示如下：

sequenceDiagram

participant C as 客户端

participant S as 服务器

C->>S: ClientHello(版本、套件、key_share)

S->>C: ServerHello(key_share)、EncryptedExtensions

S->>C: Certificate、CertificateVerify、Finished

C->>S: Finished

Note over C,S: 握手完成，改用应用流量密钥

C->>S: 应用数据(AEAD 保护的记录)

发展历程

协议的前身是网景公司(Netscape)在 1990 年代中期为网页浏览器设计的安全套接层(Secure Sockets Layer，SSL)^[1]。SSL 1.0 因存在严重缺陷从未公开发布，SSL 2.0 于 1995 年随浏览器一同提供，但被指出多项安全问题；1996 年发布的 SSL 3.0 对协议作了较大改写，将数据传输层与消息层分离，并支持 Diffie-Hellman 密钥交换^[2]。SSL 2.0 与 SSL 3.0 后来分别由 RFC 6176 和 RFC 7568 正式废止。

1999 年 1 月，互联网工程任务组(IETF)以 RFC 2246 发布 TLS 1.0，把这一协议转为开放标准，其内容与 SSL 3.0 差别不大。此后 IETF 于 2006 年 4 月发布 TLS 1.1(RFC 4346)，2008 年 8 月发布 TLS 1.2(RFC 5246)，后者成为长期使用的主流版本。

2014 年，研究人员公布针对 SSL 3.0 的分组密码填充缺陷，促使业界弃用该版本，IETF 随后以 RFC 7568 将其废止^[1]。同年 IETF 的 TLS 工作组启动 TLS 1.3 的重新设计，历经 4 年、28 份草案，于 2018 年 3 月获批，并于 2018 年 8 月作为 RFC 8446 正式出版^[3]。

TLS 1.3 在结构上作了大幅精简：只保留基于 AEAD 的对称算法，删除静态 RSA 与静态 Diffie-Hellman 密钥交换，要求所有公钥密钥交换具备前向保密性，ServerHello 之后的握手消息全部加密，弃用重协商、通用压缩、DSA 证书与自定义 DHE 组，并把会话恢复统一为 PSK 机制。与 TLS 1.2 相比，完整握手由 2 个往返缩短为 1 个往返，另提供 0-RTT 模式，但该模式不具备完全前向保密性，且不保证不被重放。

应用

最广泛的用途是保护网页流量。以 TLS 加密的 HTTP 通常称为 HTTPS，约定使用 443 端口，而未加密的 HTTP 默认使用 80 端口。经过 HTTPS 的页面流量在用户代理与服务器之间加密传输，用户可以据此确认所连接的服务器身份。

邮件是另一个常见场景：SMTP、IMAP、POP 等协议通过 STARTTLS 机制在原有会话中升级为加密连接，DNS-over-TLS、FTPS 等也以同样方式获得加密保护^[4]。即时通信、VoIP、网络传真等应用同样广泛支持这一协议^[5]。

对虚拟主机托管场景，服务器名称指示(SNI)扩展让客户端在握手早期告知目标域名，使同一 IP 与端口上承载的多个站点各自使用自己的证书。为降低重复建连的开销，TLS 还支持会话恢复，以缩短的握手复用此前的会话状态。

局限

协议只保护传输中的数据，无法弥补端点自身的疏忽。规范明确指出，TLS 不能防止许多常见的实现与配置错误，例如随机数生成器不合格、证书链未经验证等。若使用裸公钥或不校验证书链，连接便无法抵御主动的中间人攻击。

机密性也有边界。规范说明 TLS 并不隐藏所传数据的长度，端点只能通过填充记录来削弱流量分析的效果；基于报文长度与时序的流量分析在 TLS 上仍然可行，协议本身没有专门的防御手段。此外，0-RTT 数据不具备完全前向保密性，也不保证不被重放，应用必须自行限定可在这种模式下发送的消息类型。

协议同样不提供事后安全性。一旦某条连接的流量密钥泄露，攻击者便可据此推算该连接后续的流量密钥，需要重新握手才能恢复保障。TLS 1.3 加密了握手的大部分内容以保护证书等元数据，但客户端首次发送的服务器名称仍未加密，这也使得基于名称的识别与拦截仍然可能。

兼容性方面，TLS 1.3 与旧版本不能直接互通，需要依赖版本协商机制回退到双方共同支持的版本。规范还提到，大量中间设备在遇到 TLS 1.3 握手时会表现异常，因此协议专门设计了让握手在外观上接近 TLS 1.2 的兼容模式。主流浏览器自 2020 年初起已停止支持 TLS 1.0 与 1.1。

参见

• SSL —— TLS 的前身，由网景公司设计，其 3.0 版是 TLS 1.0 的直接基础。

• HTTPS —— 在 HTTP 之下叠加 TLS 而形成的安全网页传输方案。

• X.509 —— TLS 用于承载公钥与身份信息的证书格式。

• 握手协议 —— TLS 中负责协商参数、认证身份与建立共享密钥的子协议。

• 前向保密 —— TLS 1.3 强制要求密钥交换具备的性质，长期私钥泄露不影响历史会话。

• 互联网工程任务组 —— 负责制定与维护 TLS 各版本标准的标准化组织。