当前位置：首页 > news >正文

【计算机网络】第22篇：传输层安全——TLS握手协议的状态机与密钥派生

news 2026/5/8 10:15:15

1. TLS在协议栈中的位置

2. TLS 1.3握手的两种模式

2.1 (EC)DHE握手：一个往返的密钥交换

2.2 PSK握手：零往返的会话恢复

3. HKDF密钥派生链

3.1 从共享秘密到会话密钥

3.2 密钥分离与方向隔离

4. 前向安全性与0-RTT的张力

4.1 前向安全性的数学保证

4.2 0-RTT的重放攻击

5. 证书链验证与信任锚

6. 结语

参考文献

1. TLS在协议栈中的位置

TLS位于TCP与应用层协议之间。从分层模型的角度，TLS为应用层提供两个基本保证：服务器身份认证（通过证书链）和通信内容的加密与完整性保护。应用层将HTTP、WebSocket或其他应用数据写入TLS记录层，TLS加密后通过TCP发送。接收端解密后交还原始应用数据。

TLS 1.2及之前版本的握手包含两次往返，显式协商加密算法套件，服务端证书明文传输。TLS 1.3（RFC 8446）在2018年发布，对握手协议进行了实质性重构——默认使用带前向安全性的(EC)DHE密钥交换，移除了静态RSA和CBC模式等已知存在安全风险的选项，将握手的绝大部分升级为加密传输。

理解TLS 1.3的握手，本质上是理解两个核心过程：身份认证密钥交换如何在一个往返内完成，以及从共享秘密到会话密钥的派生链如何保证不同方向的密钥相互独立。

2. TLS 1.3握手的两种模式

2.1 (EC)DHE握手：一个往返的密钥交换

TLS 1.3的(EC)DHE握手将TLS 1.2的两次往返压缩为一次。

客户端在首条握手消息（ClientHello）中不仅提供支持的密码学套件和随机数，还直接包含密钥交换参数。客户端生成一个临时ECDH密钥对，将公钥通过key_share扩展发送给服务器。客户端同时猜测服务器最可能接受的椭圆曲线组，在支持的组列表中发送对应公钥。若猜测正确，服务器可直接使用该公钥完成密钥交换，节省一次往返。

服务器收到ClientHello后，选择密码学套件，生成自己的临时ECDH密钥对，用双方公钥计算ECDH共享秘密。服务器发送ServerHello（携带所选参数和自己密钥交换的公钥）、加密的EncryptedExtensions（确认参数）、Certificate（服务器证书链）、CertificateVerify（用服务器证书私钥对握手记录签名以证明证书拥有权）、Finished（用派生出的握手流量密钥对整个握手记录做MAC，验证协商一致性）。服务器将证书和签名用握手密钥加密后再发送，防止中间人观察证书信息和业务类型。

客户端验证证书链和服务器签名后，发送自己的Finished消息。至此客户端确认服务器真实拥有所出示证书的私钥，服务器确认客户端能正确派生会话密钥，握手在应用数据首字节发出前完成。

与TLS 1.2对比，TLS 1.3的(EC)DHE握手节省了一整个往返。TLS 1.2需要ClientHello/ServerHello第一次往返完成算法协商，第二次往返交换密钥和证书。TLS 1.3将密钥交换公钥嵌入ClientHello，服务器可在收到首条消息后直接完成密钥派生和加密证书的发送，握手的通信延迟减半。

2.2 PSK握手：零往返的会话恢复

若客户端之前与服务器建立过TLS连接，可以从上次连接协商中获得PSK（预共享密钥）。客户端在ClientHello中携带PSK标识符和PSK密钥交换扩展。服务器在ServerHello中选择同意使用的PSK，后续仍然需要发送EncryptedExtensions和Finished，但证书和签名步骤可以跳过，因为身份已由PSK间接认证。

PSK模式将完整握手从一轮往返再压缩至一轮往返（与(EC)DHE相同），但节省了证书链传输和签名验证的计算开销。在大型TLS终止网关中，PSK会话恢复能显著降低CPU负载。

3. HKDF密钥派生链

3.1 从共享秘密到会话密钥

(EC)DHE握手完成后，客户端和服务器共享两个关键秘密材料。一是(EC)DHE计算出的共享秘密，二是PSK（若使用）。TLS 1.3定义了一个规范化的密钥派生流程，使用HMAC-based Key Derivation Function（HKDF）从这些原始材料派生出所有会话密钥。

HKDF分为两个阶段：提取阶段和扩展阶段。提取阶段将输入密钥材料（ECDHE共享秘密和PSK）与固定salt混合，通过HMAC-Hash产生一个固定长度的伪随机密钥（PRK）。扩展阶段将PRK和上下文信息（握手记录哈希、密钥标签）作为输入，通过HMAC-Hash迭代产生任意长度的输出密钥材料。

这种设计将密码学安全的密钥派生与协议上下文的语义绑定分离。提取阶段仅依赖输入密钥材料的安全性，扩展阶段按需生成指定长度的密钥字节。

3.2 密钥分离与方向隔离

TLS 1.3从一个统一的握手秘密开始，逐级派生出多个独立密钥。

早期秘密（从PSK和ClientHello派生）→ 早期流量密钥（保护0-RTT数据）。握手秘密（从早期秘密和ECDHE共享秘密派生）→ 客户端握手流量密钥与服务器握手流量密钥（保护握手的加密部分，包括证书和Finished）。主秘密（从握手秘密和握手记录零值派生）→ 客户端应用流量密钥与服务器应用流量密钥（保护握手完成后的应用数据）。

每一个派生步骤的标签不同（例如"c hs traffic"标识客户端握手流量密钥，"s ap traffic"标识服务器应用流量密钥），保证不同用途的密钥密码学上相互独立。即使攻击者通过侧信道获得握手流量密钥，也无法计算出应用流量密钥，因为HKDF的扩展阶段输入了不同的标签和上下文。

方向隔离同样由派生步骤保证。客户端和服务器在不同方向使用独立的密钥加密，避免同一密钥在两个方向上使用相同的初始化向量导致密码学安全问题。

4. 前向安全性与0-RTT的张力

4.1 前向安全性的数学保证

前向安全性是指长期密钥（服务器证书私钥）在未来被泄露时，不能从记录的密文中解密出过去的会话内容。

(EC)DHE通过临时密钥对实现这一保证。握手时双方生成一次性的ECDH密钥对，派生出的共享秘密在握手完成后立即删除，密文记录中没有存储该随机密钥对的信息。攻击者即使事后获取服务器证书私钥并解密出握手阶段的密文，仍无法重建ECDH共享秘密，无法解密应用数据。

非前向安全的静态RSA密钥交换则相反。服务器证书私钥直接用于加密预备主密钥，密文中包含用服务器公钥加密的密钥材料。一旦服务器私钥在未来泄露，所有此前的密文记录可被解密。TLS 1.3移除静态RSA密钥交换正是为了消除这个无前向安全性的设计残余。

4.2 0-RTT的重放攻击

0-RTT允许客户端在首次数据包中就携带应用数据——用从PSK派生的早期流量密钥加密。这个数据在服务器完成握手之前已进入应用层处理。但0-RTT数据没有前向安全性——早期流量密钥仅从PSK派生，未混入临时的ECDHE共享秘密。更重要的是，0-RTT数据不具有抵御重放攻击的能力。

中间人可以在网络层录制客户端的0-RTT数据包，在连接关闭后重新发送给服务器。服务器收到重放的0-RTT数据，因PSK仍在有效期内，验证通过后将重复的应用数据递给后端应用。如果0-RTT携带的是非幂等请求——例如POST提交表单或转账操作——重放将导致重复的操作副作用。

TLS 1.3为0-RTT提供了有限的重放防御机制。服务器可在SessionTicket或NewSessionTicket消息中携带发送限制（如最大0-RTT字节数和过期时间），并在检测到重放时通过单边连接关闭终止处理。但协议本身无法在密码学上区分重放的0-RTT数据与原发数据——这要求应用层只将0-RTT用于幂等GET请求或带应用层重放令牌的POST请求。

0-RTT体现了安全性与性能的根本张力。将延迟从一往返压缩至零往返的同时，必然牺牲端到端交互性提供的重放防护。这个张力不是TLS 1.3的疏忽，而是零延迟语义与安全认证之间的根本限制。任何零往返协议要么重放非幂等操作，要么需要应用层额外的重放检测令牌。

5. 证书链验证与信任锚

TLS 1.3的证书验证与1.2基本相同——服务器发送服务器证书及其中间CA证书链，客户端验证证书链的签名直到信任锚（根CA证书）。TLS 1.3要求证书状态通过OCSP装订或CRL证明保持有效，服务器在握手中附带OCSP应答签名，减少客户端独立的证书状态查询延迟。

SNI（服务器名称指示）在TLS 1.3中加密传输——Encrypted ClientHello扩展将SNI从明文的ClientHello中移至加密扩展。这一改进阻止了中间人观察目标域名元数据，但对企业网络的合规性监控带来了新的策略配置要求。

6. 结语

TLS 1.3的握手协议通过对(EC)DHE的显式优先、状态机的精简和2-RTT到1-RTT的压缩，完成了从TLS 1.2逐步演进到实质性优化的一跳。HKDF将密钥派生过程规范化为提取与扩展两阶段，实现了会话密钥、握手密钥和应用密钥的密码学隔离。前向安全性由临时密钥对提供，0-RTT为会话恢复省去延迟但引入了重放攻击风险，二者之间的张力只有通过应用层幂等处理的语义边界来管理。

理解TLS握手不是记忆各类消息的顺序，而是理解身份认证、密钥协商与流量加密三者如何在有限状态机内协同完成，以及每种优化（如减少往返、0-RTT）在安全性上的对应代价。