エンドツーエンド暗号化は追加の保護層であり、TLS 警告を無視したり改ざんされたコードを信頼したりする許可ではありません。
TLS とエンドツーエンド暗号化は、それぞれ異なる境界を作ります。これらの境界は VPN やプロキシの評価でも重要です。TLS は通常、端末とサービスの間の接続を保護します。一方、正しく実装され認証されたエンドツーエンド暗号化は、会話の内容を受信者の端末まで保護します。TLS 層を読めることは、必ずしもエンドツーエンドの内容を読めることを意味しません。しかし、だからといって TLS の安全性が重要でなくなるわけではありません。
中継者が安全な接続を終端できる場合、転送データを見るだけでなく、応答や Web アプリのコードを変更できる可能性もあります。そのため、「LVR1 で TLS を回避する」という表現は、メッセンジャーの安全性を適切に説明していません。
ルート証明書はどのように検査を可能にするのでしょうか？
HTTPS 接続では、端末はサーバーの証明書チェーンとホスト名を検証します。中継者が提示した証明書をアプリが有効と判断すれば、中継者はユーザーとの接続と、本物のサーバーとの接続という、別々の二つの接続を作れる可能性があります。この場合、中継者は一方の TLS 接続の終端です。パケットを眺めるだけで暗号を破った傍受者ではありません。
任意の証明書をインストールするだけでは不十分です。アプリがその証明書を信頼し、接続の検証にも合格する必要があります。Android のネットワーク セキュリティ構成ドキュメントでは、信頼ポリシーはアプリごとに異なり得ると説明されています。Android 7.0 以降を対象とするアプリは、別途構成されていない限り、ユーザーが追加した証明書をデフォルトでは信頼しません。
これは一般的な技術的仕組みです。証拠なしに、これを根拠として特定の通信事業者、国、出来事について判断することはできません。接続障害やフィルタリングだけでは、TLS の検査が成功した証明にはなりません。
TLS が開かれると何が見えるのでしょうか？
| データの種類や状況 | TLS 検査で起こり得る結果 |
|---|---|
| HTTPS だけで保護された内容 | 信頼された中継者が平文を見られる可能性がある |
| 受信者の有効な鍵ですでに暗号化されたメッセージ | 中継者が通常目にするのは、メッセージの平文ではなく暗号文 |
| ルーティング、セッション、補助的なリクエストのデータ | 露出の程度はサービスの形式と設計に依存する |
| 同じ経路で届く Web 版のコード | コードの変更がエンドポイントの安全性を脅かす可能性がある |
| サービスの停止や通信の遮断 | 暗号化だけでは接続を確立できない |
E2EE による内容の保護は、受信者の鍵の真正性と、双方のソフトウェアの健全性にも依存します。攻撃者が最初の鍵を差し替えたり、暗号化前のメッセージを見るアプリが改ざんされたりすれば、AES や ML-KEM があるだけでは十分ではありません。
なぜ Web 版には安全な TLS が必要なのでしょうか？
Web アプリは通常、実行するコードをサーバーから受け取ります。そのコードが悪意あるものなら、暗号化前や復号後の内容にアクセスできます。コードの配信方法や実行方法と切り離して、エンドツーエンド暗号化を評価することはできません。
インストール版でも、パッケージの真正性、更新、OS の健全性は重要です。パッケージ署名やハッシュの確認は有用ですが、アプリの安全性を完全に試験するものではありません。Livara の脅威モデルでも、攻撃者がファイルと表示されたハッシュの両方を変更した場合、ハッシュの一致だけでは真正性を証明できないと述べられています。
Livara は何を主張しているのでしょうか？
Livara のセキュリティドキュメントによれば、ダイレクトメッセージには LVR1、対応する非公開グループには LGS1 が使われます。ドキュメントは P-256 と ML-KEM-768 の組み合わせ、およびメッセージ内容の暗号化について説明しています。これらは製品側の主張であり、この記事における独立した監査の結果ではありません。
同じページには、ルーティング用メタデータを保持することと、配信チャンネルが公開であることも示されています。したがって、正しい結論は「すべての情報が隠れる」でも「ネットワークを一切信頼する必要がない」でもありません。非公開の内容の保護は、接続、鍵の配信、アプリのコード、メタデータとは分けて検討すべきだということです。
証明書警告にはどう対処すればよいのでしょうか？
- 機密性の高いチャットを続けるために、ブラウザーやアプリの警告を無視しないでください。
- 端末の日付とサービスの正確なアドレスを確認してください。証明書エラーがすべて攻撃とは限りません。
- 組織の端末であれば、管理ポリシーやインストール済みの証明書について、権限のある管理者に確認してください。管理対象の設定を独断で変更しないでください。
- 知らない相手からのメッセージに頼まれたというだけで、証明書やプロファイルをインストールしないでください。
- 機密性の高い会話では、独立した経路で相手と鍵のフィンガープリントを照合してください。鍵の照合は TLS 警告を解消する代わりにはなりません。
よくある質問
VPN はこれらの問題をすべて解決しますか？
いいえ。VPN は通信を観察される経路を変えられますが、感染した端末、信頼された悪意ある証明書、改ざんされた Web コードを自動的に修復するわけではありません。
パスワードを送信しない認証だけで十分ですか？
いいえ。認証プロトコル、セッション管理、メッセージ暗号化は異なる役割を持ちます。偽のログインページや悪意あるコードは、プロトコルが動く前にユーザーの入力そのものを取得できます。
実践の原則： E2EE は価値のある保護層です。証明書、アプリの真正性、鍵の検証を無視する許可だと考えないでください。
