QUIC 本身并不比 TCP、UDP、HTTP ... 更危险。重要的是使用协议传输的内容。如果您仅将防火墙用作简单的数据包过滤器并且不进行任何内容检查（即恶意软件、URL 过滤器等），那么是否允许 QUIC 并不重要。相反，如果您的防火墙用于分析 HTTP(s) 流量，那么丢弃 QUIC 流量可能是一个好主意，这样浏览器将继续使用 HTTP(s) 并且不会使用您的防火墙不理解的协议绕过分析。

2019 年 2 月 9 日更新：来源：新的 TLS 加密破坏攻击也会影响较新的 TLS 1.3

“来自世界各地的七名研究人员再次发现了另一种破解 RSA PKCS#1 v1.5 的方法，这是当今用于加密 TLS 连接的最常见的 RSA 配置。除了 TLS，这种新的 Bleichenbacher 攻击还适用于谷歌的新的 QUIC 加密协议也是如此。”

==================================================== ====

以前的评论：“攻击可用于拒绝客户端访问任何选择的应用程序并导致服务器浪费资源！” 到目前为止，还不是特别危险。下面提到的所有内容都只会导致拒绝服务（连接）和断开连接，仅此而已。

https://www.ietf.org/proceedings/96/slides/slides-96-irtfopen-1.pdf

QUIC 使用 0-rtt（会话恢复/票证），这可能容易受到重放攻击，如此处所述；tls也是如此；tls 0-rtt 可以在 firefox 中禁用，但我不确定目前是否有选项可以在浏览器中禁用 quic 的 0-rtt。在进一步挖掘之后，即使是 quic 1-rtt（连接握手）（截至本文发表时间为 2015 年）也容易受到 MITM、服务器配置重放攻击、源地址令牌重放攻击和数据包操纵攻击：

我们在攻击中针对 QUIC7 的 Chromium 实现，因为这是规范的实现。我们的攻击是使用 scapy 库在 python 中开发的。我们在表 1 中总结了我们的攻击、它们的属性和影响。重放攻击。服务器配置重放攻击。要进行这种攻击，攻击者必须首先收集目标服务器的 scfg 的副本。这可以通过主动建立与服务器的连接或通过被动侦听客户端尝试连接来完成。在任何一种情况下，都可以从完整的 1-RTT QUIC 连接握手中轻松收集服务器的 scfg。一旦攻击者拥有 scfg，他就会等待目标客户端尝试启动连接。当攻击者看到来自客户端的 ac hello 消息时，

SRC https://eprint.iacr.org/2015/582.pdf

请注意，这篇文章写于 2015 年，从那时起协议可能已经发展。

我同意 Steffan 的观点，即 QUIC 并不比 TCP、UDP、HTTP 或任何其他通信协议更危险。我认为对于您的用例，真正重要的是通过协议传输的数据。

就像 Steffan 所说，这实际上取决于防火墙以及您尝试使用该防火墙解决的问题。进行非正式的威胁建模（您主要关心什么样的攻击/威胁参与者？您试图使用防火墙保护什么样的资产？）并在有关 QUIC 的问题中分享您的一些具体问题实际上会帮助其他人提供明确的答案。

谈论协议本身的安全性——我不是协议安全方面的专家，但根据我的理解，所有通信协议在被宣布为标准之前都经过了安全研究人员和专家的大量审查（通常通过 RFC）。在这方面，QUIC 还没有 TCP 或 UDP 或 HTTP 成熟，但围绕协议进行了大量的安全研究。

我能够检索到的最相关的研究是 QUIC 有多安全和快速？可证明的安全性和性能分析 - Lychev 等人。作者基本上介绍了一个安全模型来分析像 QUIC 这样的性能驱动协议，并证明 QUIC 在协议构建块的合理假设下满足他们的定义。