Quic 0RTT详解

最新推荐文章于 2024-09-13 19:45:12 发布

fdsafwagdagadg6576

最新推荐文章于 2024-09-13 19:45:12 发布

阅读量2.3k

点赞数 2

分类专栏：传输文章标签： quic 网络协议

本文链接：https://blog.youkuaiyun.com/fdsafwagdagadg6576/article/details/122437517

版权

传输专栏收录该内容

9 篇文章

订阅专栏

系列文章：DTLS详解_fdsafwagdagadg6576的专栏-优快云博客_dtls

1、基本概要

QUIC handshake中有两个加密密钥, initial key 和 forword-secure key。
前者用于实现 0-RTT 的握手，后者则用于握手成功以后整个会话的数据加密；
QUIC 的密钥使用 Diffe-Hellman 算法生成；

2、Diffe-Hellman 算法的密钥生成过程

Alice 和 Bob 都知道两个素数（g、p）的存在
Alice 有 a（private key）；Bob 有 b（private key）
有了上面的前提，Diffe-Hellman 的算法流程如下：

1、Alice 计算 A=g^a mod p，并发送 A 给 Bob；
2、Bob 计算 B=g^b mod p，并发送 B 给 Alice；
3、此时，Alice 计算 B^a mod p，Bob 计算 A^b mod p，
4、分解可得，
B^a mod p = (g^b mod p)^a mod p = g^ab mod p = K；
A^b mod p= (g^a mod p)^b mod p = g^ab mod p = K;

于是，双方都有了一个共享密钥 K，关于 Diffe-Hellman 的数学原理，可参考这篇英文帖子。

3 QUIC 加密握手的过程

了解了 Diffe-Hellman 算法生成共享密钥的原理，我们来看看 QUIC 的两个密钥是怎样生成的。

这里的通信两端分别是 QUIC client（Alice）和 QUIC server（Bob），具备的前提是：

QUIC client 和 QUIC server 已知密钥交换算法（即已知 g、p）；
QUIC client 有 ephemeral Diffe-Hellman private value ;
QUIC server有 long-term Diffe-Hellman private value,ephemeral Diffe-Hellman private value,为了方便描述我这里分别简写为：C-DH-E-pri（即a），S-DH-L-pri(即b)，S-DH-E-pri(即c)。

3.1 RTT scenario:

client 发送给server Inchoate CHLO(明文)
server 发送给client REJ. REJ 包含server config(即B) 等信息.
client收到server config(即B)之后，client本地计算出第一个秘钥 init key 即K（B^a mod p = (g^b mod p)^a mod p = g^ab mod p = K）
client 发给server Complete CHLO（complete CHLO 并未加密）.complete CHLO 中包含了client 的ephemeral Diffie-Hellman public value(即 A)
server收到Complete CHLO之后，server本地计算出第一个秘钥 init key 即K（A^b mod p= (g^a mod p)^b mod p = g^ab mod p = K）
client 发给server Encrypted request(使用K加密)
server 发给client SHLO(使用K加密) .SHLO 包含了 server 的 ephemeral Diffe-Hellman public value(即c)
server 本地生成，第二个秘钥forward-secure key（比如：c*K）
client 收到server发送的c之后，本地生成第二个秘钥forward-secure key（同样c*K）
server 发给client Encrypted response (使用 forward-secure key 加密)
之后，client,server都使用forward-secure key加密发送数据

3.2 0RTT scenario:

a) 成功
1RTT scenario的3,4,5,6

b) 失败
1）执行1RTT scenario的3,4失败，server发送REJ给client（比如：server config 即B已经timeout）
2） server发送REJ，相当于1RTT的第2步，发送了新server config(即B1)
3），4），5），6）和1RTT一样。
0RTT 成功的情况，client缓存1RTT时候，收到的server config和source-address token.所以client可以直接发送加密数据。省了1个RTT.
0RRT 失败的情况，实际和1RTT是一样了.

补充：服务器会返回REJ消息，它包括:

服务端的配置server config，里面包含服务端的DH算法的long-term public value
对服务器进行身份认证的certificate chain
server config签名(使用证书链的叶子证书的public key加密)
source-address token：认证加密的block，包含了客户端的公开可见的IP地址和服务端的一个时间戳。客户端在接下来的握手中发送这个token到服务端，验证其IP地址的所有权。

接收到这个REJ消息后，客户端会进行解析认证，缓存必要的配置