TLS関連の情報を含むWiresharkトレースを公にアップロードすることの潜在的なリスク？
たとえば、一般に公開されているWebサイトにWiresharkのトレースをアップロードするとします。これで、SSLキーログ、証明書情報などが利用可能になったとしましょう。誰かが痕跡へのリンクを持っている場合、どのような危険性がありますか？
明らかに、特定のトレースセッションの内容と情報は誰にでも表示されます。過去または将来のセッションについてはどうですか。他のクライアントまたは他のサーバーで発生したセッションはどうですか？リプレイ攻撃や中間者攻撃などの危険にさらされる可能性はありますか？
Wiresharkトレースがパッシブ盗聴者の観点から作成された場合、将来のSSL/TLS接続を改ざんするために使用できるトレースは何もありません。
ワイヤレスホットスポットオペレーター、ISP、バックボーンキャリア、データセンターなど、作成したものと同じトレースを行うことができる多くのエンティティがあることに注意してください。将来のSSL/TLS接続を改ざんすることが可能であった場合あなたが作成したトレース、これらのエンティティのいずれかが同じことを行う可能性があります。 SSL/TLSは、この種の改ざんに対して耐性を持つように特別に設計されました。
クライアントでトレースを実行し、セッション情報をSSLKEYLOGFILEに記録したとしても、このファイルには一時的なキーとセッションキーのみが含まれるため、このファイルの情報は将来のSSL/TLS接続の改ざんには役立ちません。トレースが行われたときのセッション。
誰かがパケットキャプチャにのみアクセスでき、他のキーマテリアルにはアクセスできない場合、サーバー名（SNI）やTLS 1.2のサーバー証明書などの暗号化されていないデータは表示できますが、暗号化されたデータは表示されません。 TLSは、第三者によるセッションの改ざんを防止し、リプレイ攻撃を防止するように設計されています。
SSLKEYLOGFILE環境変数によって生成されたファイルは、通常、セッションごとのシークレットを格納し、エンドポイント（クライアントまたはサーバー）によって書き込まれます。その形式は https://developer.mozilla.org/NSS_Key_Log_Format に記載されています。
TLS 1.3の場合、ログに記録されたシークレットはその特定のセッションでのみ使用できます。これらのシークレットは、他のセッションの復号化には使用できません。これには、以前のセッション、将来のセッション、および他のクライアントまたはサーバーとのセッションが含まれます。その理由は、秘密が 派生 であり、完全なハンドシェイクメッセージのトランスクリプトからです。ハンドシェイクを変更すると（たとえば、異なるクライアントランダムまたは異なるサーバー名）、異なるシークレットが生成されます。
TLS 1.2以前の場合、状況はほとんど同じです。ただし、2つの例外があり、将来のセッションのセキュリティが損なわれます。
- 当事者がRSA鍵交換の使用に同意した場合、セッションは転送秘密になりません。つまり、証明書に一致するサーバーのプライベートRSAキーが危険にさらされた場合、そのプライベートキーの所有者は、同じサーバーキーに基づいて、以前および将来のすべてのセッションを解読できます。これは、両方の当事者がDiffie-Hellman鍵交換に基づくフォワードシークレット暗号スイートを使用する場合は適用されません。後者のセッションは、RSA秘密鍵が漏洩した場合でも安全です。
- TLS 1.2では、マスターシークレットはセッションにリンクされています。 セッションの再開は、クライアントが以前のセッションのマスターキーを再利用できるメカニズムです。これは、識別子（セッションIDまたはセッションチケット）をサーバーに送信することによって行われます。サーバーがこれを認識すると、完全なハンドシェイクをスキップして、新しいキー交換を実行せずに省略されたハンドシェイクを完了します。 マスターシークレットをプライベートに保つための要件 に違反しているため、新しい接続は安全ではありません。
2番目の問題は微妙ですが、非常に重要です。これはTLS 1.3で解決されており、すべてのセッションには常に完全なキー交換が含まれているため、ハンドシェイクとアプリケーションデータの暗号化に使用される実際のシークレットとは無関係に「再開シークレット」が作成されます。
TLS 1.2セッション再開の問題を示す例：
- Wiresharkキャプチャを開始し、SSLKEYLOGFILE環境変数を設定してFirefoxを開きます。
- メールやウェブショップなどのウェブサイトにアクセスします。
- ある時点で、キャプチャされたパケットトレースに満足し、Wiresharkキャプチャを停止します。 SSLKEYLOGFILEファイルの内容とともに、そのコピーを作成します。
- あなたはウェブサイトのタブを閉じることにしましたが、Firefoxを終了せずにです。これは通常、ネットワーク接続を終了します。
- ウェブサイトを見るのはつまらなかったし、インスピレーションを得て、ウェブサイトを再び開いた。これにより、新しい接続が作成されます。
- あなたはウェブサイトにログインするか、メールを送るか何かを購入します。
- 最後に、元のキャプチャとキーを共有します。
ここでの問題は、ステップ5がTLS 1.2セッション再開を使用してしまう可能性があることです。ネットワークトラフィック（コーヒーショップのパブリックWi-Fiネットワークなど）を見るパッシブ攻撃者（MitM）は、ステップ7のシークレットを使用して、ステップ6のアクティビティを解読できます。パスワード、そしてそれでひどいことをしてください。
話の教訓：はい、パケットキャプチャをSSLKEYLOGFILEと共有しても安全ですが、気にしないセッションのキーのみが含まれていることを確認してください。共有用のトレースを作成する場合は、仮想マシンを使用するか、別の参照プロファイルを使用します。後者の例は、WiresharkでのTLS復号化の実行に関する私のスライドのスライド8にあります。 https://lekensteyn.nl/files/wireshark-tls-debugging-sharkfest19eu.pdf
新しいブラウジングプロファイルを開始できない場合は、少なくともキャッシュをクリアしてみてください。これにより、次の新しい接続で新しいキーが使用されるようになります。
質問の中でそれを述べましたが、完全を期すためにもう一度繰り返します。復号化されたトレースは、キャプチャセッション中に共有したCookie、URL、画像、Webページコンテンツ、およびその他の詳細を明らかにする可能性があります。ローカルキャプチャを停止しても、他の誰かが盗聴して既存の接続のすべてをキャプチャしている可能性があります。シークレットを公開すると、その接続のすべてを解読できます。