Page 229 - 《软件学报》2021年第9期

陆思奇 等:强安全模型下 TLS1.3 协议的形式化分析与优化 2853

如果网页加载延迟 100ms,销售量就会随之减少 1%.而对于服务器在地理位置上相距很远的用户来说,网络的
延迟则更加不能忽略.因此,人们希望既不牺牲安全性又能够尽量地降低协议的运行时间.针对这一需
求,TLS1.3 做出了如下改进.
(1) RTT 握手支持;
(2) RTT 数据支持.
RTT 是 Round Trip Time 的缩写,即消息的往返时间.对于 TLS1.2 来说,完成一次握手需要两个 RTT:第 1 个
是 ClientHello 和 ServerHello,用于协商密钥交换算法以及各种不同的密码参数;第 2 个是 ClientKeyExchange
和 ServerKeyExchange,也就是使用前一个 RTT 协商的算法和参数进行密钥交换.TLS1.3 为了减少 RTT,决定取
消第 1 个 RTT,让客户端缓存最近服务器使用的算法和参数,直接使用该缓存的算法和参数,与服务器进行密钥
交换.如果客户端使用的算法和参数错误,则服务器返回 HelloRetryRewuest 消息,告知正确的算法和参数,让客
户端重启握手,这就是 1-RTT 握手.该握手方式的可行性来源于 TLS1.3 对算法的削减,许多不安全的算法被抛
弃,剩下的密钥协商算法其实只有屈指可数的几种.而可用的密钥协商算法越少,那么 1-RTT 握手成功的可能性
就越高;并且即使客户端使用了错误的算法,也只需要增加一个 RTT 的代价,和 TLS1.2 相比没有增加额外的
RTT.这样,TLS1.3 基本没有副作用,便大大降低了 TLS 握手协议所需要的平均时长.
除了上述的 1-RTT 握手,TLS1.3 还借鉴了 Google 的 QUIC 协议 [31] ,设计了一个 0-RTT 数据的解决方案.所
谓 0-RTT,是指在握手协议的第 1 条消息中就允许客户端发送一些数据而不必等到握手协议结束.具体的解决方
法是:允许客户端缓存服务器的长期公钥,在第 1 条消息中直接利用该长期公钥生成一个会话密钥发送部分应
用层数据,另一部分应用层数据则等到完整的握手协议之后发送.在现实应用中,对于近期曾经访问过的网站,
用户可以在第 1 次向服务器发送消息时就带上一部分应用数据,从而达到提高网页加载速度的目的.
值得注意的是:0-RTT 数据只是在 1-RTT 握手的基础上添加的数据,这个数据也被称为 Early Data,握手的其
他部分依然保持 1-RTT 原有的消息.另外,这些数据不能抵抗重放攻击,该漏洞可通过一些独立于密钥交换的其
他机制解决,如果想要利用 0-RTT 机制,则应该在应用层提供重放保护.
2.3 支持0-RTT数据的模式

TLS1.3 有 3 种模式支持 0-RTT 数据:1-RTT semi-static,PSK,PSK-DHE.图 3 为包含 0-RTT 数据的消息交互
过程,表 1 表示各部分交互消息的意义,表 2 为 3 种模式所使用的密钥导出表.

⎯⎯⎯⎯⎯⎯⎯⎯→
chello,ceks,{Early Data}
eadk
←⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
shello,seks,{ssks,MAC
sfk (chello,ceks,shello,seks,ssks)}
htk
Client Server
Fig.3 Handshake process that contains 0-RTT data flow
图 3 包含 0-RTT 数据的握手流程
Table 1 Protocol notation
表 1 符号定义
chello,shello 密钥协商参数
x
ceks,seks 临时公钥 g ,g y
ssks 服务器长期公钥 g s
+
ssks 签名服务器密钥
Table 2 Key derivation table
表 2 密钥导出表
模式 ceks seks ssks sfk eadk atk htk cost
xs
xs
1-RTT semi-static g x g y g s g xs g g ,g xy g xy 2DH
PSK − − − psk psk psk psk −
PSK-DHE g x g y − psk psk psk,g xy g xy 1DH