QUIC协议如何实现0RTT加密传输（插件）

本篇文章给大家谈谈QUIC协议如何实现0RTT加密传输（插件），以及对应的知识点，文章可能有点长，但是希望大家可以阅读完，增长自己的知识，最重要的是希望对各位有所帮助，可以解决了您的问题，不要忘了收藏本站喔。

此外，对于HTTPS 等应用，由于需要额外的TLS 握手，0RTT 更是不可能。

如果Certificate太大或太长，则需要3个以上的RTT才能完成握手.

S（即服务器

服务器）和C

C（即客户端

客户端）而不是A

A（即爱丽丝

爱丽丝）和B

B（即鲍勃

我跳过DH

DH算法进行密钥协商。

步骤0：配置服务器SS密钥对，在SS中生成一个素数pp和一个整数gg（gg是pp的原根，不懂的可以跳过），并随机生成一个数字KpriKpri。计算： Kpub=gKprimod pKpub=gKpri mod p 将{p,g,Kpub}{p,g,Kpub} 三元组键入配置包中。步骤1：CC首次发起连接。 CC 只是将Client Hello 发送给SS。步骤2：SS第一次使用config响应CCSS，封装成数据包回复CC，其中显然包含{p,g,Kpub}{p,g,Kpub}元组。步骤3：CC发送加密数据。 CC收到{p,g,Kpub}{p,g,Kpub}后，随机生成一个数Kc_pri。 Kc_pri 进行如下计算：计算公钥： Kc_pub=gKc_primod pKc_pub=gKc_pri mod p 计算对称密钥：K1=KKc_pripubmod pK1=KpubKc_pri mod p 准备业务数据Payload1，设置加密函数为Enc(key,data)Enc( key,data)，并将以下元组D1D1 发送到SS： D1={Kc_pub,Enc(K1,payload1 )}D1={Kc_pub,Enc(K1,payload1)} 请注意，在该阶段开始时，有效负载为加密的。步骤4：SS发送加密数据。 SS收到D1D1后，进行如下计算：计算对称密钥：K1=KKpric_pubmod pK1=Kc_pubKpri mod p。可以证明CC侧的K1K1和K1K1相等： K1=KKpric_pubmod p=(gKc_primod p)Kprimod p=gKc_priKprimod pK1=Kc_pubKpri mod p=(gKc_pri mod p)Kprimod p=gKc_priKpri mod pK1=.=gKpriKc_primod p=gKc_priKprimod p=K1K1=.=gKpriKc_pri mod p=gKc_priKprimod p=K1 因此K1K1 可以将密文Enc(K1,payload1)Enc(K1,payload1) 解密为获取明文负载。也许你会认为K

K1可以作为后续通信的对称密钥，但事实并非如此。对于所谓的前向安全，此时S

S将继续生成第二个对称密钥K

SS在发送自己的payload2之前，随机生成一个数字Kn_priKn_pri，并进行如下计算：计算新的通信公钥： Kn_pub=gKn_primod pKn_pub=gKn_pri mod p 计算新的通信对称密钥： K2=KKn_pric_pubmod pK2=Kc_pubKn_pri mod phas 得到后新的通信对称密钥K2K2，可以将以下元组发送给CC： D2={Kn_pub,Enc(K2,payload2)}D2={Kn_pub,Enc(K2,payload2)} 在这个元组D2D2 中除了加密数据之外SS的Enc(K2,payload2)Enc(K2,payload2)，还包括SS新生成的公钥。步骤5：CC接收来自SS的D2D2。 CC收到SS发来的D2D2后，解出Kn_pubKn_pub，并执行以下操作：计算新的通信密钥： K2=KKc_prin_pubmod pK2=Kn_pubKc_pri mod p（可以证明K2=K2K2=K2） Payload2可以被解密正确使用K2K2。在后续的通信中，SS和CC可以使用K2K2作为通信对称密钥。值得注意的是，这个K2K2是在1个RTT内新生成的。虽然协商这个K2K2需要1个RTT，但业务数据在这个RTT中仍然可以加密通信，但是使用了K1K1。也就是说，使用由CC存储器中的SS侧配置协商的“不安全”密钥。该密钥仅对数据加密一次。步骤6：断开CC 和SS。通信一段时间后，SS和CC断开连接。第七步：CC直接发送加密数据。过了一段时间或者一段时间后，CC想要再次与SS通信。注意，此时CC已经有了SS的配置元组{p,g,Kpub}{p,g,Kpub}，也许CC缓存在内存中，也许写入磁盘，不管怎样，只要CC有{ p,g,Kpub}{p,g,Kpub}，可以直接从第3步开始，即直接通过{p,g,Kpub}{p,g,Kpub}计算出一个对称密钥自己生成的随机数私钥，然后直接发送payload。嗯，这就是所谓的0RTT。步骤8：SS发送加密数据。 SS收到来自CC的加密数据后，重复步骤4重新计算新的“安全对称密钥”，该密钥可以用作直到断开连接为止的对称密钥。整个流程如下图所示：

好了，介绍结束了。

因此，QUIC的0RTT加密数据传输并不是无条件的。不过请注意，QUIC的0RTT与Session复用的一般思路完全不同：

SS不保存任何关于CC的信息；连接发起的0.50.5 RTT使用的密钥是临时的，下一个0.50.5 RTT使用的密钥将重新计算。在整个过程中，我们可以体会到DH算法的一些特点。从步骤2和步骤3可以看出，这个算法是真正的按需协商，即只有真正需要密钥时才会进行实际操作，大大减少或基本消除了离线处理的需要。攻击的机会，此外，DH算法非常简单易用。

据说QUIC作为一个试验场，很多想法都会转移到更标准化的标准上，比如BBR到TCP（不过我很看好TCP，BBR继续在QUIC上发展不是更好吗？）？）。 0RTT同样的思路也将被吸收到正在进行中的TLS1.3版本中，令人非常期待。

这一切都归功于谷歌，一家伟大的公司。从看到HTTP的缺点到SPDY，再到HTTP2.0，再到看到TCP的缺点，QUIC直接衍生自SPDY/HTTP2.0。在QUIC本身的演进过程中，也选择了TCP。善者随之，不善者改之。这就是我们现在接触到的QUIC协议，它将HTTP2.0和TCP集成到了大成的QUIC协议中。

不管怎样，我个人还是比较看好QUIC的。