アカウント名:
パスワード:
HTTP/3が普及すると必然的にQUICが普及することになるので、何でもUDP/443に乗せて通信するという地獄のような状態が始まる。「今までも既にTCP/443でそうだった」といえばそれまでなんだが、QUIC使ったアプリケーションの実装面ではUDP/443上にTLSで作ったトンネルでいろんなアプリケーションプロトコルを流すものが多いので、ファイアウォールやエンドポイントセキュリティではポート番号等である程度判別がついていたものを、UDP/443できたデータグラムの中身をTLSオフロードした上で、完全にペイロード解析しないといけない。という状況に陥るので、今まで以上にセキュリティに対するコストが高くなるのが問題。
会社のセキュリティ担当は今までは単純にQUIC自体を許可しない方向で動いていたと思うけど、これが徐々にできなくなる可能性を秘めているから頭抱えていると思う。
エンドポイント側（端末側）で統制かける方法が今風で、ネットワークペリメータにゲートウェイおいてHTTPSの中身見るなんて時代遅れすぎると思うけど。
流行りで言うならゼロトラスト且つ多層防御なので、できるならどっちもやるのが今風よ。
ゼロトラストなんて営業用語でしかなく、現実のセキュリティレベルは常にコストとのトレードオフで決まる。
ゼロトラストには種類ある皆を疑い慎重に行動するものと皆を疑うがなぁなぁで済ませるものだ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
ついに地獄が始まる(ファイアウォール/エンドポイントセキュリティ) (スコア:1)
HTTP/3が普及すると必然的にQUICが普及することになるので、何でもUDP/443に乗せて通信するという地獄のような状態が始まる。
「今までも既にTCP/443でそうだった」といえばそれまでなんだが、
QUIC使ったアプリケーションの実装面ではUDP/443上にTLSで作ったトンネルでいろんなアプリケーションプロトコルを流すものが多いので、
ファイアウォールやエンドポイントセキュリティではポート番号等である程度判別がついていたものを、
UDP/443できたデータグラムの中身をTLSオフロードした上で、完全にペイロード解析しないといけない。
という状況に陥るので、今まで以上にセキュリティに対するコストが高くなるのが問題。
会社のセキュリティ担当は今までは単純にQUIC自体を許可しない方向で動いていたと思うけど、これが徐々にできなくなる可能性を秘めているから頭抱えていると思う。
Re: (スコア:1)
エンドポイント側（端末側）で統制かける方法が今風で、
ネットワークペリメータにゲートウェイおいてHTTPSの中身見るなんて時代遅れすぎると思うけど。
Re: (スコア:0)
流行りで言うならゼロトラスト且つ多層防御なので、できるならどっちもやるのが今風よ。
Re: (スコア:0)
ゼロトラストなんて営業用語でしかなく、現実のセキュリティレベルは常にコストとのトレードオフで決まる。
Re:ついに地獄が始まる(ファイアウォール/エンドポイントセキュリティ) (スコア:0)
ゼロトラストには種類ある皆を疑い慎重に行動するものと皆を疑うがなぁなぁで済ませるものだ。