SSL終了メッセージの内容
ハンドシェイクプロトコル中に使用される終了メッセージの内容について少し混乱しています。特に、このメッセージ（クライアント側）には、サーバーから最初に送信された接続IDが含まれており、以前のすべてのハンドシェイクメッセージとマスターシークレットから派生したハッシュ値も含まれています。
したがって、このメッセージはマスターシークレットから導出されたキーで暗号化されますか、それとも接続IDのみが暗号化され、完了メッセージは引き続きプレーンで送信されますか？
もう1つの質問は、サーバーサイドでのリプレイ攻撃の検出についてです。サーバーはクライアントから完了メッセージを受信します。サーバーはどのようにFinished Messageからのリプレイ攻撃を正しく検出できますか。また、なぜconnection-idを使用して1つだけをハッシュするだけでは不十分なのでしょうか。
Finishedメッセージに「connection-id」はありません。さらに言えば、 SSL/TLS全体の標準 には「接続ID」の概念はまったくないようです。最も近い概念は、セッションIDの概念であり、ClientHelloおよびServerHelloメッセージを介して交換されます。 Finishedメッセージ。定義により、セッションIDは単一の接続に固有のものではありません。
Finishedメッセージの内容は、以前に交換されたすべてのハンドシェイクメッセージに対して双方向で計算されたハッシュです。 FinishedメッセージはChangeCipherSpecの後に送信され、新たにネゴシエートされた暗号化アルゴリズムとキーで保護されます。つまり、暗号化され、MAC化されます。
リプレイ攻撃に対する保護は、Finishedメッセージの内容の計算方法に依存します。ハッシュはすべてのハンドシェイクメッセージに対して行われるため、特にclient_randomおよびserver_random要素が含まれますクライアントとサーバーの両方から送信されます。攻撃者は定義上、正規のサーバーと通信中にクライアントを再生するか、正規のクライアントと通信中にサーバーを再生するため、両方のランダムを再利用することはできません。
SSLウォークスルーとして、私は この答え をお勧めします。
あなたの質問は明確ではありませんが、私が理解できることについてお答えします。ただし、最初に、TLSプロトコルの最も信頼できるリファレンスは、基本的なRFC 2246、4346、および5246であり、いくつかのオプション機能（特定の拡張機能など）が使用されたときに他のRFCによって拡張されます。あなたはそのような詳細な質問のためにそれらを読むべきです。
Finishedメッセージには、PRF ofマスターシークレット、方向フラグ、およびハンドシェイクメッセージのハッシュ（使用されている場合はHelloReqを除く）が含まれています。 SSL/TLSには 'connection-id'はありませんが、サーバーからServerHello;で送信される通常（常にではない）の 'session-id'があります。 ServerHello全体と他のすべてのハンドシェイクメッセージがハンドシェイクハッシュに含まれます。
Finishedメッセージは各方向（クライアントからサーバー、サーバーからクライアント）に送信されます。シーケンスは、完全なハンドシェイクを行うか、省略されたハンドシェイク（再開）を行うかによって異なります。 Finishedメッセージは、ChangeCipherSpecに続くすべてのメッセージと同様に、マスターシークレットとクライアントナンスとサーバーナンスの両方から派生したキーを使用して暗号化され、HMACされます（またはHMACを必要としないAEAD暗号化されます）。 。 Finishedの正しい復号化と認証は、基本的にマスターシークレットに関する合意を証明します。これは最初に暗号化されたメッセージである必要があるため、ユーザーデータが公開される前に不一致の検出を保証します。
同じ接続でメッセージを再生すると、無視されるか、プロトコル違反になるため、役に立たなくなります。あなたの意図した攻撃は、以前に有効だったFinishedを、何らかの新しい接続試行の一部として再生しているものと想定します。異なるハンドシェイクに同じFinishedを使用すると、一致せず失敗します。同じハンドシェイクをもう一度実行できる場合にのみ機能しますが、少なくともナンス、および多くの場合、いくつかのプリマスター入力も、他の（レギット）パーティーによって新しく選択され、異なるため、機能しません。