盗まれた TLS 検査 CA 鍵は記録済みのセッションを復号できるか

「攻撃者がプロキシの秘密鍵を盗んだ」という説明では、被害の大きさを決める肝心な点が抜けています。どの秘密鍵なのか、という点です。

TLS を検査するフォワードプロキシは、認証局の署名鍵、生成したサーバー証明書の鍵、稼働中の TLS 通信の秘密、セッション再開用の材料、平文を自身のメモリやログに保持することがあります。これらは別々の資産です。

CA 鍵が与えるのはなりすましの能力

検査用 CA を信頼するよう設定されたクライアントは、証明書チェーンの制約とクライアント側の検査の範囲で、その CA の下で発行された証明書を受け入れられます。対応する署名鍵を盗んだ者は、その制約内で別の受け入れ可能な証明書を作れる可能性があります。

これは重大ですが、鍵だけでは利用者の接続を別の宛先へ変えることはできません。攻撃者には、使える位置での傍受か、なりすました端点へクライアントを接続させる別の手段も必要です。追加の証明書検査を行うアプリケーションは拒否する場合があります。

署名鍵は記録の復号鍵ではない

証明書で認証する TLS 1.3 のハンドシェイクで一時的な Diffie–Hellman を使う場合、証明書はやり取りを認証します。通信鍵は別個のハンドシェイク秘密から導出されます。後から CA 署名鍵を入手しても、それだけで記録から過去の一時的な秘密が再構成されるわけではありません。

サーバー証明書の秘密鍵を盗むことすら、その種の記録済みセッションの通信秘密を得ることとは同じではありません。これをあらゆる過去の TLS 方式やあらゆる再開設定に一般化しないでください。交渉された鍵交換と漏えいした材料が重要です。

稼働中の検査アプライアンスの侵害は、その CA 鍵の窃取よりはるかに広い範囲に及ぶことがあります。アプライアンスは通信を検査する際に平文を扱い、セッション秘密を保持したり、復号済みの内容を保存したりする場合があります。そうした露出は独自の調査を要し、前方秘匿性を挙げて片付けられるものではありません。

事故を正確に描写する

失われたのが署名鍵なのか、端点の鍵なのか、稼働中の秘密なのか、保存された平文なのか、アプライアンス自体の制御なのかを記録してください。検査用 CA を交換しクライアントの信頼を更新することは一つの能力への対処であり、複製されたログを消すことも、稼働中の通信が読まれたかを決めることにもなりません。正確な鍵の名称は、あらゆる秘密を「SSL 鍵」と呼ぶよりはるかに有用な対応につながります。