WSS トンネルの暗号化はアプリではなく TLS 終端で止まる

wss:// の URL が証明するのは一つのホップ上の TLS だけです。ペイロードが独自の暗号化を持つかどうかは、クライアントが中に何を入れるか、そして誰がその TLS を終端するかで決まります。

安全な WebSocket の中を運ばれるトンネルの暗号化は、クライアントが中に入れた分だけであり、それ以上ではありません。wss:// というスキームは、TLS が一つのホップ上で一つの接続を守ることを示します。WebSocket メッセージの中のバイト列が別途保護されているかどうかについては何も語りませんし、途中の何かが TLS を終端するとき、あなたのトラフィックを誰が読めるかを決めるのはこの違いです。

一つのように見える二つの層

安全な WebSocket とは、その上で WebSocket のハンドシェイクが行われる TLS であり、RFC 6455 が接続とセキュリティの各節で説明しているとおりです。TLS 層がサーバーを認証してストリームを暗号化し、その上で WebSocket 層がアプリケーションの送るものをフレーム化します。

これは二つの独立した判断であり、経路全体に一つの鍵を描く図は二つ目を隠してしまいます。TLS 接続を誰が終端するかを尋ねてください。次に、クライアントが各メッセージの中に何を置くかを尋ねてください。配備についての残りはすべて、この二つの答えから導かれます。

設計 A: 輸送が唯一の暗号化

より単純な設計では、クライアントは生の IP パケットを取り、WebSocket メッセージに包みます。中身は暗号化されないため、TLS セッションを持つコンポーネントは平文のペイロードを読みます。そのコンポーネントが自前のトンネルサーバーである場合、これは意図された終端であり、設計は整合していますし、サーバーはもともとトラフィックを見る立場でした。

経路上に検査プロキシが座り、クライアントが信頼する証明書で TLS を終端すると、話は別の構成になります。そのプロキシは、サーバーが持ったはずの平文をそのまま持ち、WebSocket のフレーミングをどれだけ重ねてもそれは変わりません。クライアントの信頼ストアが、トンネルが開くずっと前にこの結果を決めていました、その名前に対してその証明書を受け入れると選んだからです。プロキシは要求されたホストと各メッセージの大きさも見えており、それだけで、これ以上何も復号せずに多くの活動の指紋を取れます。

設計 B: ペイロードが自前の鍵を運ぶ

二つ目の設計では、クライアントは独自のピア識別と鍵交換を持つ VPN プロトコルでパケットを暗号化・認証し、その結果を WebSocket メッセージの中に運びます。ここで外側の TLS を終端しても露出するのは暗号文であり、トラフィックではありません。プロキシが見えるのはメッセージの大きさとタイミングだけで、ペイロードの中の他のものは見えません。これははるかに小さな露出であり、それでもレビューで名指しする価値のあるメタデータであって、手を振って片付ける話ではありません。

内側のプロトコル自身の終端は依然として平文を見ますが、それがこの構成の狙いであり、同時に限界でもあります。終端上のコンポーネントが暗号化の前や復号の後にデータを読む権限を持つなら、追加の層はそれを制約しません。鍵と、鍵を扱うソフトウェアが、意味のある境界として残ります。

VPN のラベル、見慣れたクライアントのアイコン、マーケティングページは、この設計が存在する証拠にはなりません。ペイロードの形式を読むことが証拠です。

平文が実際にどこに現れるかを追う

URL のスキームが与える事実は一つだけなので、残りはインターフェースから得てください。以下の確認はどれも次を狭めるので、順番に実行してください：

ss -tnp | grep -E ':(443|8443)\b'
ip -br link show type tun
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
tcpdump -ni tun0 -c 5 -X

外側の接続から始めます。TLS ポートへの長命な TCP セッションが一本あるのが WebSocket キャリアの姿であり、無関係なホストへの二本目のセッションは、より深く見る前に説明を要します。次にクライアント上のトンネルインターフェースを見つけますが、tun や tap のデバイスがあれば、クライアントが単一のアプリケーションストリームをプロキシしているのではなく IP パケットを扱っているとわかります。

トンネルインターフェースでのキャプチャが、通常はペイロードの問いに決着をつけます。そこに読めるヘッダーがあれば内側のパケットは決して別途暗号化されておらず、高エントロピーのペイロードなら暗号化されていたとわかります。外側のインターフェースでもキャプチャを繰り返して両方を比べ、どちらもランダムに見えるなら、内側の層は外側が取り消せない仕事をしています。

実際に与えた信頼を見直す

インストールされた企業ルート証明書は、クライアントの信頼ストアについての事実であり、どのプロキシが何を記録・検査するかについての声明ではありません。CA の存在から挙動を推測するのではなく、配備された方針と実際の接続経路を確定してください。

管理された機器では、どのコンポーネントが TLS を終端するのか、クライアントはピン留めされた証明書を検証するのか公開証明書を検証するのか、ペイロードの形式は何かを管理者に尋ねてください。その三つの答えが、後で弁護できる所見になります。

結果は判決ではなく境界として書いてください。「TLS は検査プロキシで終端し、内側のペイロードはエンドポイントだけが持つ鍵で別途暗号化されている」は、ベンダーが変わっても通用する検証可能な記述です。「WebSockets は安全だ」は通用しません。

関連記事