それで、いくつか質問があります：
1) TLS 中にクライアント証明書を使用すると、否認防止が提供されますか?
1a) フォローアップ: もしそうなら、ロードバランサーにトランザクションを処理させることは、エンドサーバー/サービスレベルでこの保証を提供しますか?
2/2a) 上記と同じ質問ですが、メッセージの完全性に関する質問です。
MLS の答えはわかっていますが、TLS についてはわかりません。私が正しく理解していれば、TLS には共有シークレットが確立されるハンドシェイクが含まれ、それはパイプを保護するために使用されます。したがって、各メッセージは共有シークレットのみを使用するため、これらのどれも保持されません。
- TLS 中にクライアント証明書を使用すると、否認防止が提供されますか?
1a) フォローアップ: もしそうなら、ロードバランサーにトランザクションを処理させることは、エンドサーバー/サービスレベルでこの保証を提供しますか?
TLS はトランスポートレベルのセキュリティに関するものです (そのため、トランスポート層セキュリティという名前が付けられています)。仕様に従って、クライアントとサーバー (ロードバランサーの可能性あり) 間の通信を保護することを目的としています。
TLS プロトコルの主な目的は、
通信する 2 つのアプリケーション間でプライバシーとデータの整合性を提供することです。
原則として、TLS 交換全体を保持できます。特に、ハンドシェイクを保持して、クライアント証明書が証明書検証メッセージの内容に署名したことを証明できます。また、生成/計算されたさまざまな中間値 (特にマスター シークレット、その後の共有キー) を保持する必要があります。これには 1 つの問題があります。TLS 仕様では、プレマスター シークレットを削除する必要があります ("should" のみ)。これにより、データからクライアント証明書に戻るパスを証明することがかなり難しくなる可能性があります。(これもすべて記録するには、SSL/TLS スタックを微調整する必要があります。)
さらに、これらすべての記録は、アプリケーション プロトコルの下で行われます (ここでは HTTPS を想定していますが、他のプロトコルにも同じことが当てはまります)。これは確かに、否認されたくない実際のデータに到達する前の別のレイヤーになります。(問題は、証明のためにセッション全体を記録しなければならない場合があり、分離する要求/応答を選択することができないことです。)
セッションの再開 (たとえば) や一般的な並列リクエストに関しては、さらに問題が発生する可能性があります。これは間違いなく混乱を招くでしょう。
全体として、これは TLS の設計目的ではありません。否認防止とは、交換の証拠を保持できることであり、法廷などで提示できる可能性があります。興味深いデータとクライアント証明書をリンクさせる方法を (技術的なバックグラウンドを持っていない可能性がある) 人に説明するのは難しい場合があります。
2/2a) 上記と同じ質問ですが、メッセージの完全性に関する質問です。
TLS は通信の完全性を保証します (仕様の概要を参照してください)。(もちろん、これはすべて、クライアントがサーバー証明書を正しく検証することを前提としていますが、クライアント証明書を使用している場合は MITM を検出できるはずです。)
完全性は、TLS 接続が終了する時点までのみ保証されます。ロードバランサーを使用している場合、これはロードバランサー自体になります。(もちろん、信頼できるネットワークを介してロードバランサーをそのワーカーノードにリンクすることをお勧めします。)
クライアントが否認防止メッセージを送信でき、後で監査できるシステムを求めている場合は、メッセージレベルのソリューションを検討する必要があります。