アカウント名:
パスワード:
HTTP/3が普及すると必然的にQUICが普及することになるので、何でもUDP/443に乗せて通信するという地獄のような状態が始まる。「今までも既にTCP/443でそうだった」といえばそれまでなんだが、QUIC使ったアプリケーションの実装面ではUDP/443上にTLSで作ったトンネルでいろんなアプリケーションプロトコルを流すものが多いので、ファイアウォールやエンドポイントセキュリティではポート番号等である程度判別がついていたものを、UDP/443できたデータグラムの中身をTLSオフロードした上で、完全にペイロード解析しないといけない。という状況に陥るので、今まで以上にセキュリティに対するコストが高くなるのが問題。
会社のセキュリティ担当は今までは単純にQUIC自体を許可しない方向で動いていたと思うけど、これが徐々にできなくなる可能性を秘めているから頭抱えていると思う。
セキュリティが目的ならポートだけで信じちゃうのはまずいんじゃないの?どのポートを使ってようがペイロード見なきゃ安全かなんてわからんでしょ。
最近のちょっとしたよさげなファイアウォールだと、ポート番号で判別する場合はそのポート番号で動作するとアプリケーション制御で規定したプロトコルの流れに合ってなければすぐ落とせるのよ。だからポート番号を活用することでリソース削減ができる。
それがQUICだとプロトコルの流れがTLSトンネルの中で、且つポート番号も多くのアプリケーションが443つかっているから、基本全量検査になるので負荷爆上げですな、って話。これは「xxx over HTTPS」の流れの時から既に、443番ポートはペイロード完全監視監視対象下にしていることが多いとは思うけど、今までポート番号を443以外を使っていたところもQUICに合流されると、負荷爆上げで上位モデル買わなきゃいけなくなるからお財布に優しくない。
監視やれめればいいじゃん。とてもお財布にも優しい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
ついに地獄が始まる(ファイアウォール/エンドポイントセキュリティ) (スコア:1)
HTTP/3が普及すると必然的にQUICが普及することになるので、何でもUDP/443に乗せて通信するという地獄のような状態が始まる。
「今までも既にTCP/443でそうだった」といえばそれまでなんだが、
QUIC使ったアプリケーションの実装面ではUDP/443上にTLSで作ったトンネルでいろんなアプリケーションプロトコルを流すものが多いので、
ファイアウォールやエンドポイントセキュリティではポート番号等である程度判別がついていたものを、
UDP/443できたデータグラムの中身をTLSオフロードした上で、完全にペイロード解析しないといけない。
という状況に陥るので、今まで以上にセキュリティに対するコストが高くなるのが問題。
会社のセキュリティ担当は今までは単純にQUIC自体を許可しない方向で動いていたと思うけど、これが徐々にできなくなる可能性を秘めているから頭抱えていると思う。
Re: (スコア:0)
セキュリティが目的ならポートだけで信じちゃうのはまずいんじゃないの?
どのポートを使ってようがペイロード見なきゃ安全かなんてわからんでしょ。
Re: (スコア:0)
最近のちょっとしたよさげなファイアウォールだと、ポート番号で判別する場合はそのポート番号で動作するとアプリケーション制御で規定したプロトコルの流れに合ってなければすぐ落とせるのよ。
だからポート番号を活用することでリソース削減ができる。
それがQUICだとプロトコルの流れがTLSトンネルの中で、且つポート番号も多くのアプリケーションが443つかっているから、基本全量検査になるので負荷爆上げですな、って話。
これは「xxx over HTTPS」の流れの時から既に、443番ポートはペイロード完全監視監視対象下にしていることが多いとは思うけど、
今までポート番号を443以外を使っていたところもQUICに合流されると、負荷爆上げで上位モデル買わなきゃいけなくなるからお財布に優しくない。
Re:ついに地獄が始まる(ファイアウォール/エンドポイントセキュリティ) (スコア:0)
監視やれめればいいじゃん。
とてもお財布にも優しい。