はじめに
Cato クラウドでは、Internet Firewall のベストプラクティスとして QUIC プロトコル (QUIC Service と GQUIC Application) の通信をブロックすることが推奨されています。これはドキュメントの Internet and WAN Firewall Policies – Best Practices のページだけでなく、他の複数のページにも同様のことが書かれています。
また、CASB 機能の1つである Application Control を有効にすると、QUIC プロトコルをブロックするルールが Internet Firewall の上位に自動的に作られるようにもなっています。
本記事では QUIC プロトコルの仕組みについて簡単に触れつつ、QUIC プロトコルをブロックすべき理由やブロックすることで生じる問題点について解説します。
QUIC プロトコルとは
QUIC とは、2021年5月に IETF にてインターネット標準として定められた通信プロトコルであり、TCP と同様に信頼性の高い通信を行うためのトランスポート層のプロトコルです。現在のところ、トランスポート層として QUIC を利用するアプリケーションプロトコルとしては、HTTP/3 のみインターネット標準として定められています。
QUIC は比較的新しいプロトコルではあるものの、10年ほど前に Google が公開したプロトコルが基となっており、既に多くの Web サイトや Web サービスが QUIC および HTTP/3 を採用しています。また、主要なブラウザ (Google Chrome, Microsoft Edge, Mozilla Firefox など) も HTTP/3 に対応しており、ご自宅などの環境では HTTP/3 でインターネットと通信が行われているはずです。
実際、私の自宅から Google のトップページを Google Chrome で表示させ、デベロッパーツールで通信の内容を確認すると次のようになっていました。
デベロッパーツールの “Protocol” という列が “h3” となっているリクエストは、HTTP/3 で通信されたことを表しています。(“h2” は HTTP/2 で通信されたことを表しています。)
また、私個人として Web サイトを AWS の CloudFront という CDN サービスを用いて公開していますが、CloudFront も HTTP/3 に対応していますので、私個人の Web サイトも HTTP/3 でアクセスできるようにしています。
このように、HTTP/3 は普通のインターネット利用者が気付かない形でどんどん普及しており、その下では QUIC プロトコルによるトラフィックも多く流れているという状況にあります。
QUIC プロトコルの構造
QUIC と HTTP/3 についてもう少し詳しく説明します。
QUIC はトランスポート層のプロトコルですが、IP ではなく UDP の上に構築されたプロトコルです。すなわち、IP パケットのデータ部に UDP パケットがあり、UDP パケットのデータ部に QUIC パケットがあるという構造となっています。
この構造により、ネットワーク機器が QUIC を扱えなくても、UDP 通信の制御により QUIC 通信の可否を制御できるようになっています。HTTP/3 は通常 443 番ポートを利用して通信しますので、アウトバウンド方向に UDP 443 番ポートの通信が許可されていれば、HTTP/3 通信を行えるということになります。
QUIC プロトコルをブロックすべき理由
さて、Cato クラウドでは Internet Firewall で QUIC プロトコルをブロックすることが推奨されていますが、ブロックしないとどのような問題が起きるのでしょうか。
ドキュメントの Internet and WAN Firewall Policies – Best Practices のページには次の一文が記載されています。
Since the QUIC protocol works over UDP 443, encapsulated HTTP traffic is not parsed.
Cato クラウドは HTTP/3 通信の内容を解析しないと述べられています。つまり、HTTP/3 通信に対して Cato クラウドは TLS インスペクションを行わず、Application Control や DLP といった CASB の機能も働かないということを示しています。
CASB 機能は Cato クラウドの魅力の1つでもあり、この機能が働かないというのは困ります。そのため、QUIC プロトコルをブロックして HTTP/3 通信を行えないようにすることで、CASB 機能が働く HTTP/2 や HTTP/1.1 による通信に限定しようというのが先の Internet Firewall のブロックルールの意図です。
この対応は理想的な内容ではありませんが、Cato クラウドの現状の仕様を考慮すると最善の対応であると思います。
ブロックすることで生じる問題点
通信できなくならないか
Cato クラウドで QUIC プロトコルをブロックすることで、別の問題が発生しないか気になるのではないでしょうか。これについては、問題は概ね発生しないと断言して良いと思います。
通常、ブラウザは最初に HTTP/2 や HTTP/1.1 で Web サーバと通信を開始し、レスポンスに Web サーバが HTTP/3 に対応しているかどうかを示すヘッダ (Alt-Svc ヘッダ) が含まれていれば、次からは HTTP/3 で通信しようとします。しかし、QUIC プロトコルがブロックされているとブラウザは Web サーバとの間で HTTP/3 接続を確立できないため、引き続き HTTP/2 や HTTP/1.1 で通信を行います。そのため、QUIC プロトコルをブロックしても Web サーバと通信ができなくなることはありません。
ただし、ブラウザ以外のソフトウェア (モバイルアプリケーションや PC 上で動作するデスクトップアプリケーションなど) については上記の限りではありません。通信を HTTP/3 にアップグレードしたり、HTTP/3 で通信できずにフォールバックしたりする仕組みはソフトウェアの実装依存ですので、ソフトウェアが適切に作られていないと正常に動作しないケースがあるかもしれません。
その他懸念点
他にもいくつか懸念点はあります。
最大の懸念点としては、Cato クラウドのベストプラクティスに従い QUIC プロトコル (QUIC Service と GQUIC Application) をブロックするようにしたとき、QUIC 以外の通信もブロックされてしまわないかという点です。UDP 通信の中身が QUIC かどうかを確実に見分ける方法はないため、Cato クラウドが QUIC ではない何らかの UDP 通信を誤ってブロックしてしまう可能性があります。
QUIC プロトコルをブロックするというルールが実際にどのような条件に該当する通信をブロックするのか仕様として公開されていないため、誤ったブロックの可能性を拭えません。そのため、イベントログにて誤ったブロックが発生していないか定期的に確認し、誤ったブロックが見つかれば明示的に Allow するルールを追加するといった運用が必要となります。
また、些細な懸念点としては、ブラウザが HTTP/3 通信を試みてから HTTP/2 や HTTP/1.1 にフォールバックするまで、通信が待たされてしまうという点です。実際にどの程度の時間待たされるのかはブラウザ次第であり、過去には数十秒待たされることがありましたが、現在はほとんど気にならない程度になっていると感じています。他にも、通信できない無駄な UDP トラフィックが発生するというのも少し気になります。
これについては、Cato クラウドが HTTP/2 や HTTP/1.1 通信のレスポンスヘッダから Alt-Svc ヘッダを除去してくれれば、ブラウザが HTTP/3 通信を試みることがなくなりますので、Cato クラウドの機能改善を待ちたいところです。
まとめ
本記事では QUIC プロトコルをブロックするというベストプラクティスに関して、技術的な背景や新たな課題について整理しました。
現状では CASB 機能を正しく働かせるために QUIC をブロックすべきなのは間違いありませんので、ベストプラクティスに従ってルールを追加することを推奨します。一方で、誤ったブロックが発生する可能性などの懸念点もありますので、利用者側でイベントログをもとにした運用も必要となってきます。
QUIC という新しい通信プロトコルは現在は HTTP/3 でしか利用されていないものの、他のアプリケーションプロトコルで活用するための議論が IETF で活発に行われています。将来 HTTP/3 以外で QUIC 通信が増えてくると、Cato クラウドの機能やベストプラクティス自体もまた変わってくるはずですので、通信プロトコル界隈の動向には今後も目を離せませんね。