没有合适的资源?快使用搜索试试~ 我知道了~
首页QUIC 加密协议规范中文版
资源详情
资源推荐
摘要
QUIC加密协议是QUIC的一部分,它为连接提供了传输安全性。QUIC加密协
议是
注定要消亡
的。未来它将由TLS 1.3替代,但在TLS 1.3 最终启用之前
QUIC需要一个加密协议。
借助于当前的QUIC加密协议,当客户端已经缓存了关于服务器的信息时,它
可以无需往返就建立一个加密的连接。TLS,相反地,至少需要两次往返
(算上TCP的3次握手)。QUIC握手应该比普通的TLS 握手(2048-bit
RSA)高效大约5倍,而且安全等级更高。
源地址欺骗
Internet上的协议很少能在无需至少一个初始化往返的情况下就可以工作的。
大多数协议由于TCP而需要一个往返,基于TLS的协议在应用数据可以传输
前,需要至少额外的一个或更多往返。
这些往返都交换nonces:在TCP的情况下是序列号(或SYN cookies),在
TLS的情况下是密码学随机值(client_random 和 server_random)。TCP
nonce防止IP地址欺骗,而TLS nonce防止重放攻击。任何想要寻求减少往返
的协议都不得不以某种方式解决这两个问题。
作为一个反例,DNS是一个没有任何初始化往返的协议,因此它不得不自己
处理IP地址欺骗和重放攻击。DNS简单地忽略IP地址欺骗,并因此使镜像
DDoS攻击成为一个真正的问题。对于重放的保护,DNSSEC依赖时钟同步
和短时的签名。根据设计,这允许有限时间内的重放,由于那与DNS的缓存
语义相互协调。但那不是重放保护的严格形式,因为重放是被允许的。
在QUIC中,我们分开处理这两个问题。
IP地址欺骗问题通过给客户端分配一个,即期的,“源地址token”来处理。从
客户端的视角来看,这是透明的字节串。从服务器的视角来看,它是一个认
证的加密块(比如 AES-GCM),其中包含,至少,客户端的IP地址,和一
个服务器的时间戳。服务器将只为给定的IP给那个IP发送一个源地址token。
客户端收到token被视为对IP地址拥有所有权的证明,与TCP序列号的接收
所采用的方式一样。
客户端可以在未来的请求中包含源地址token以证明对它们的源IP地址的所有
权。如果客户端的IP地址变了,则token也过时了,或者客户端没有token,
则服务器可以拒绝连接,并返回一个新的token给客户端。但是如果客户端的
IP地址保持不变,则它可以复用源地址token以避免获取一个新token所需的
网络往返。
Token的生命周期主要与服务器有关,但由于源地址token是不记名token,
它们可能被盗取并被复用以绕过基于IP地址的限制。(尽管攻击者将无法收
到响应。)源地址token还可以被收集,并可能在IP地址的所有权发生变化之
后使用(比如,在DHCP池中)。简少token的寿命,以减少在无需额外往返
的情况下处理的请求的数量为代价来改善这两个问题。
源地址token,不像TCP序列号的交换,不要求源表现出连续的接收发送到源
IP地址的分组的能力。这允许源地址token被用于持续地请求来自于服务器的
业务,即使下行链路已经饱和,其丢包率足够高以至于不能建立TCP连接。
这种 “自 DOS” 攻击可用于 DOS 相同下行链路中的其他用户。
然后,我们注意到 类似的技巧实际上可能用于TCP,因此QUIC并没有在这
方面明显地使事情变得更糟。确实,一旦连接建立好,QUIC在包中包含了一
个熵位,并要求接收者发送它们声称已经收到的熵的散列值 - 从而解决TCP
的问题。
为了最小化延迟,服务器可以动态地决定放松源地址限制。可以想象服务器
跟踪来自不同IP地址的请求的数量,并且只有当“未请求”连接的数量超过全
局或某个IP范围的限制时,才需要源地址token。这可能是有效的,但不清楚
这是否是全球稳定的。如果大量的QUIC服务器实现了这种策略,则大量的镜
像DDoS攻击可以在它们之间分割,使得任何一台服务器都不会达到攻击阈
值。
重放攻击
在TLS中,每一方都生成一个随机数,通过强制它们在密钥中包含(假定在
所有时间唯一)该值,用于确保另一方是新的。没有往返,客户端仍然可以
包括一个随机值以确保服务器是新的,但服务器没有机会为客户端这样做。
在没有来自服务器的输入的情况下提供重放保护基本上是非常昂贵的。它需
要服务器端的一致状态。尽管如果服务器是单台机器的话这是合理的,但现
代的网站都遍布全世界。
因此,QUIC在服务器的第一次应答之前不为客户端的数据提供重放保护。这
依赖应用去确保这样的信息在被攻击者重放时是安全的。比如,在Chrome
中,只有GET请求在握手确认前发送。
握手开销
在TLS中,服务器基于客户端广告的它们支持的参数为每个连接选择连接参
数。在QUIC中,服务器的首选项完全是枚举的和静态的。它们与Diffie-
Hellman公共值一起捆绑到一个“服务器配置”中。这个服务器配置含有一个过
期时间,并由服务器的私钥签名。由于服务器配置是静态的,因而不是每个
连接都需要签名操作,而是单个签名足以满足许多连接。
使用Diffie-Hellman可用的连接密钥。服务器的 Diffie-Hellman 值在服务器配
置中发现,客户端在它的第一个握手消息中提供。由于服务器配置必须保留
一段时间,以允许0-RTT握手,这给连接的前向安全性设置了上限。既然服
务器记录了服务器配置的 Diffie-Hellman 密钥,则如果它们泄漏的话用那个
服务器配置加密的数据可能被解密。
这样QUIC提供了两个层面的保密:来自于客户端的初始数据使用服务器的服
务器配置中的 Diffie-Hellman 值加密,这可能持续几天。一接收到连接,服
务器就用一个 短暂Diffie-Hellman 值来响应,然后连接被重新计算密钥。
(相对于前向安全的TLS连接,这可能似乎提供更少的前向安全性。然而,
为了避免往返,通常在大规模部署中都会启用TLS Session Tickets。
SessionTicket 密钥足以解密连接,但为了恢复的有效性,它必须保持合理的
时间段 - 通常是几天。SessionTicket密钥和服务器配置密钥类似,且有效的
安全性实际上比QUIC要高,因为它的前向安全模式更优越。)
单个连接是通常的前向安全性的范围,但是用于一个单独的连接的短暂的密
钥,和在 60 秒内用于所有连接的密钥的安全性的差异是微不足道的。因此
我们可以在小的时间跨度中将服务器的 Diffie-Hellman 密钥生成分摊在所有
的连接上。
(由于服务器配置和 Diffie-Hellman 私有值是服务器为了处理QUIC连接所需
的所有东西,证书的私钥从不需要放在服务器上。相反,短期证书的一种形
式可以通过签署短期服务器配置并仅安装在服务器上来实现。)
剩余13页未读,继续阅读
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功