QUIC（Quick UDP Internet Connections）はファイアウォールを通過しても安全ですか？
現在、ファイアウォールはQUIC（UDP 443）トラフィックをブロックしていますが、これはGoogle Chromeではデフォルトで有効になっているようです。 QUICを許可しても安全ですか、それともすべての主要なブラウザーに実装されるまで待つ必要がありますか？
ウェブアプリケーションのパフォーマンス向上を目的としたGoogleの実験として開発されたと思います。
QUIC自体は、TCP、UDP、HTTP ...ほど危険ではありません。重要なのは、プロトコルで転送されるコンテンツです。ファイアウォールを単純なパケットフィルターとしてのみ使用し、コンテンツ検査（マルウェア、URLフィルターなど）を行わない場合は、QUICを許可してもしなくてもかまいません。代わりにファイアウォールがHTTP（s）トラフィックの分析に使用されている場合は、QUICトラフィックをドロップして、ブラウザーがHTTP（s）を使用し続け、ファイアウォールが理解しないプロトコルで分析をバイパスしないようにすることをお勧めします。
2019年2月9日更新：出典：新しいTLS暗号化バスティング攻撃も新しいTLS 1.3に影響を与える
「世界中の7人の研究者が、今でもTLS接続を暗号化するために使用される最も一般的なRSA構成であるRSA PKCS＃1 v1.5を破る別の方法を発見しました。TLSに加えて、この新しいブライチェンバッハー攻撃も機能します- Googleの新しいQUIC暗号化プロトコルも同様です。 "
================================================== ====
以前のコメント：「攻撃は、クライアントが選択したアプリケーションへのアクセスを拒否し、サーバーがリソースを浪費する原因となる可能性があります！」現在のところ、特に危険はありません。以下に示すすべてのものは、サービス拒否（接続）と接続の切断を引き起こす可能性があります。
https://www.ietf.org/proceedings/96/slides/slides-96-irtfopen-1.pdf
QUICは0-rtt（セッションの再開/チケット）を使用します。これは、リプレイ攻撃に対して脆弱である可能性があります ここで述べたように ; tlsも同様です。 tls 0-rttはFirefoxで無効にできますが、現時点でブラウザのquicで0-rttを無効にするオプションがあるかどうかはわかりません。さらに少し掘り下げた後、1-rtt（接続ハンドシェイク）もMITM、Server Config Replay Attacks、Source-Address Token Replay Attacks、Packet Manipulation Attacksに対して脆弱です（記事の執筆時点では2015）。
これは正規の実装であるため、攻撃ではQUIC7のChromium実装を対象としています。私たちの攻撃は、python= scapyライブラリを使用して開発されました。攻撃、そのプロパティ、および影響を表1にまとめます。リプレイ攻撃。サーバー構成リプレイ攻撃。この攻撃を行うには、攻撃者は最初にターゲットサーバーのscfgのコピーを収集します。これは、サーバーへの接続をアクティブに確立するか、クライアントが接続を試行するのをパッシブにリッスンすることによって実行できます。どちらの場合でも、サーバーのscfgはフルから簡単に収集できます。 1-RTT QUIC接続ハンドシェイク。攻撃者がscfgを取得すると、ターゲットクライアントが接続を開始しようとするのを待ちます。攻撃者がクライアントからのc helloメッセージを見ると、収集したscfgを使用して、ランダムにランダムにsrejectmessageで応答できます。生成されたstkとsnoの値：
SRC https://eprint.iacr.org/2015/582.pdf
この記事は2015年に書かれたものであり、プロトコルはおそらくそれ以降進化してきました。
QUICはTCPまたはUDPまたはHTTPまたはその他の通信プロトコルよりも危険ではないことをSteffanは同意します。ユースケースでは、プロトコルを介して転送されるデータが本当に重要であると思います。
Steffanが言ったように、それは本当にファイアウォール（およびそのファイアウォールを使用して対処しようとしている懸念）に依存します。非公式の脅威モデリング（どのような攻撃/脅威のアクターが主要な懸念事項ですか？ファイアウォールを使用して保護しようとしている資産の種類は何ですか？）を行い、QUICに関する質問で特定の懸念事項のいくつかを共有すると、実際には他の人を助けるでしょう明確な答えを提供します。
プロトコル自体のセキュリティについて話す-私はプロトコルセキュリティの専門家ではありませんが、私の理解に基づいて、すべての通信プロトコルは多くのことを経験します標準として宣言される前に（通常はRFCを介して）、セキュリティ研究者および専門家による精査。この点に関して、QUICはTCPまたはUDPまたはHTTPほど成熟していませんが、プロトコルに関して多くのセキュリティ調査が行われてきました。
私が取得できた最も関連性の高い調査は QUICはどのように安全かつ迅速ですか？証明可能なセキュリティとパフォーマンスの分析-Lychev et alによる 。著者は基本的に、QUICのようなパフォーマンス主導のプロトコルを分析するためのセキュリティモデルを導入し、プロトコルのビルディングブロックに関する合理的な仮定の下でQUICがその定義を満たしていることを証明します。