HTTPSクライアント認証トラフィックを署名済みドキュメントとして保存/記録することは可能ですか？
クライアントのRSA証明書（スマートカードなど）があるシナリオでは、フォームの送信（またはAJAX要求））をフォームに記録して、後で確認することができますか？クライアントが実際にその情報を送信したこと（たとえば、データの暗号化に使用される一時キーのクライアントの署名を含む）？
結果は、TCPを介したTLSトラフィックのトレースを含むバイナリblobのようなものであり、それを自己完結型にするサーバーからのデータで強化されていると考えています。
可能であれば、そのようなblobでサーバーの秘密キーを公開せずに可能ですか？また、既存のTLSライブラリを使用して、大幅な変更を加えることなく実行できますか？
番号。
この質問には、クライアント証明書なしでさらに簡単なシナリオがあります。
クライアントとサーバー間の通信セッション全体のpcapng/tcpdump/wiresharkファイルと、NSSキーログ形式のSSLKEYLOGFILEダンプを指定すると、保存されたトラフィックを復号化できるので、サーバーが送信したファイルがサーバーから送信されたことをサーバーが送信したという証拠になります。 ？
そして答えはノーです、そうではありません。
TLSは否認防止を提供しません。署名は、相手と通信したことの証明ですが、通信がいつ行われたかを証明するものではなく（gmt_unix_timeが非推奨であるため）、通信が行われたことを証明するだけではなく、通信が行われたことを証明するだけです（おそらくアプリケーションなし）。送信中のデータ）。
ハンドシェイクの後、両側の両側に同じ対称鍵が割り当てられます。双方は、期待されるキーとデータを送信、暗号化、認証した相手側を示すトランスクリプトを生成できます。それが本当かどうかを知る方法はありません。
否認防止を実現するには、接続の最後にデジタル署名を追加し、切断メッセージが受信されるまで接続全体のハッシュに署名する必要があります。しかし、TLSにはそのような機能はありません。
または、友好的な地元のsigint諜報機関が、彼らが本物であることを証明するパケットキャプチャファイルを提供し、SSLKEYLOGFILEダンプを提供する通信の片側を提供する必要があり、一部のパケットが実際にその方向に送信されたことがわかります。クリアテキストデータ。
クライアントの証明書は、クライアントの認証にのみ使用されます。クライアントが証明書を送信し、秘密鍵の所有権を証明する前に行われる鍵交換では使用されません。したがって、クライアント証明書は、トラフィックの暗号化またはMACに直接的にも間接的にも含まれていません。つまり、TLSトラフィックのキャプチャを使用して、後でクライアントが特定のデータを送信したことを証明することはできません。
サーバーが何かを送信したことの証明に関する同様の質問も参照してください： 一部のサーバーがHTTPS経由でファイルを送信したことを証明する方法 。基本的な答えは同じです：独自の秘密鍵でアプリケーショントラフィックに署名しているサイトはありませんが、暗号化とMACは、shared中に作成されたシークレットにのみ基づいています鍵交換。
https://crypto.stackexchange.com/questions/5455/does-a-trace-of-ssl-packets-provide-a-proof-of-data-authenticity にあるThomas Porninの回答を参照してください。ここでの他の回答と同様に、Thomas Porninは、クライアントによる署名を使用して、セッション中にクライアントがサーバーに送信した情報について何かを証明することはできないと説明しています。ただし、サーバーは、クライアントによる署名を使用して、クライアントが特定の時間にサーバーに接続したことを証明できる場合があります。