はじめに（この記事で分かること）#

Sessionは電話番号・メール不要のメッセンジャーで、通信はonionネットワークでルーティングされる。アカウント識別子もランダムな66文字の公開鍵である。プロトコル自体の匿名性は高い。

それでも、アプリの周辺機能が匿名性を崩す。この記事では、Sessionのリンクプレビュー機能が送信者のIPアドレスを漏らす仕組みを、Privacy Guidesフォーラムの開発者回答を含めて整理する。

前提: 脅威モデルの整理#

Sessionのリンクプレビュー問題が有効な相手は、脅威モデル入門で整理した5種類の相手のうち、主に2者だ。

リンク先のWebサーバーの運営者は、アクセスログから送信者のIPアドレスを記録する。ISPは、Sessionクライアントがクリアネットに直接接続したという事実を知る。

Sessionのonionネットワークは、メッセージの送受信を保護する。しかし、リンクプレビューの生成はonionネットワークを経由しない。

リンクプレビューでIPが漏れる仕組み#

問題の発見#

Privacy Guidesフォーラムで、2024年2月にユーザーaeromatterがSessionデスクトップクライアントの重大な欠陥を報告した。

Sessionでリンクを貼ると、クライアントがリンク先のWebサーバーにクリアネットで直接接続し、プレビュー画像とメタデータ（OpenGraphタグ、ページタイトル等）を取得する。この接続はonionネットワークを経由しないため、送信者のIPアドレスとDNS要求がリンク先のWebサーバーに露出する。

漏洩の範囲#

漏洩は、リンクを含むメッセージを送信したときだけでなく、プレビューの生成をキャンセルした場合にも起こる。クライアントは、ユーザーがキャンセルを選択する前に、リンク先にアクセスしている。

受信側は影響を受けない。受信側のクライアントは、プレビュー画像をSessionのファイルサーバーからonion経由で取得するため、受信者のIPは露出しない。

開発者の回答#

Sessionの開発者KeeJefが2025年7月にフォーラムで説明した内容は次のとおりである。

  1. 利用者がリンクを入力またはペーストする
  2. Sessionクライアントがリンク先のWebサーバーに直接接続し、プレビュー画像とメタデータを取得する。この接続で送信者のIPが露出する
  3. 利用者が送信を押す
  4. プレビュー画像は、ランダムなエフェメラル鍵で暗号化され、onionルーティングでファイルサーバーにアップロードされる
  5. メッセージには、暗号化された画像リンク、復号鍵、プレビュー情報が含まれ、onionルーティングで受信者に送られる

つまり、漏洩は送信者のIPのみであり、受信者のIPは露出しない。KeeJefは、Lokinet統合によりリンクプレビューの生成もonionルーティング経由にする計画を述べた。

onion経路の自己交差#

同じフォーラムスレッドで、「最初と最後のホップが同一ノードIPになり得る」という指摘がなされた。Lokinet統合では、「同一オペレーター・同一サブネットのノードを同一経路に使わない」ロジックが追加される予定である。

トラフィック分析耐性の限界#

Sessionの白書（getsession.org）は、自らのトラフィック分析耐性の限界を認めている。

ISPが送信者と受信者の両端を監視すると、タイミング相関でペアを発見できる。Sessionはonion requestsを低レイテンシで転送するため、パケットのタイミングパターンが漏洩の材料になる。

将来の対策として、パディング、デコイメッセージ、mixnetsの導入が検討されている。しかし、これらは実装されていない。

対処方法#

リンクプレビューの無効化#

Sessionの設定でリンクプレビューを無効化することで、クリアネットへの直接接続を防ぐ。ただし、プレビュー生成の仕組み上、無効化のタイミングによっては漏洩が既に発生している可能性がある。

SimpleXでの代替#

SimpleX Chatは、リンクプレビューの生成時にクリアネットへ直接接続しない設計になっている。SessionからSimpleXへの移行は、この問題の根本的な解決策になる。

Lokinet統合の進展を追う#

KeeJefが述べたLokinet統合は、リンクプレビューのonionルーティング化と、onion経路の自己交差防止の両方を解決する計画である。統合の進展は、getsession.orgのブログで確認できる。

教訓#

この事例が示すのは、メッセンジャーの匿名性は「プロトコル」ではなく「全機能がどのネットワーク経由で動くか」で決まるということだ。

Sessionのプロトコル自体はonionルーティングと匿名IDを提供している。しかし、リンクプレビューという周辺機能がクリアネットに直接接続することで、匿名性が崩れる。プロトコルの設計がどれほど優れていても、実装の隅々まで匿名性を確認する必要がある。

匿名メッセンジャー比較で7サービスを比較した際、SimpleXの設計（IDなし・リレーサーバーで通信を処理）は、この種の問題を構造的に回避する方向にある。

限界と残るリスク#

Lokinet統合はまだ完了していない。統合が完了するまで、リンクプレビューのIP漏れはSessionの既知の問題として存在する。

Sessionは白書で、トラフィック分析耐性の限界を認めている。ISPが両端を監視するとタイミング相関でペアを発見できる。パディング・デコイメッセージ・mixnetsは将来の対策として検討中であり、現時点では実装されていない。

まとめ#

Sessionを使う場合、リンクプレビュー機能が送信者のIPを漏らすことを理解したうえで、設定で無効化するか、SimpleXへの移行を検討する。

匿名IDを持つメッセンジャーであっても、アプリの全機能がどのネットワーク経由で動くかを確認しなければ、匿名性は崩れる。この確認は、メッセンジャーの選択時だけでなく、アップデートのたびに必要である。

出典#