対称鍵はSSL / TLSハンドシェイクでどのように交換されますか？
私はクライアントとサーバー間のSSL/TLSハンドシェイクについてたくさん読んでいます、そしてそれに関する多くの記事は非常に矛盾しています。
2つのパーティ間の通信に使用される対称鍵はクライアントからサーバーに送信される（ofc、サーバーの公開鍵で暗号化される）と言われる人もいます。
DHアルゴが使用されていて、最初にクライアントが共有キーの生成に役立つプリマスターシークレットを送信すると言う人もいます（なぜプリマスターシークレットは最初から暗号化されているので、攻撃者は機密情報を取得しません）。
混乱しているのは、共有対称鍵での生成の全体的なフローです。 a）DHは使用されていますか（使用されていない場合、対称鍵はどのように生成されますか、クライアントはそれを提案し、RSA暗号化を介して送信します。それですべてですか？）
B）DHが使用されている場合、誰が最初に開始しますか？シークレットを生成するために使用する全体的な素数を最初に提案し、次にそれらの計算を送信する（または全体的なアルゴリズムを事前に決定する）誰かがいる必要がありますか？
すでに述べたように、対称セッションキーを交換する方法は2つあります。key enciphermentまたはkey agreement（Diffie-Hellmanアルゴリズムに基づく）を使用する方法です。両方のアルゴリズムは同時に使用されません。たとえば、Microsoft SChannelクライアントはサーバー証明書のKeyUsages拡張（ビット文字列）からビットを読み取り、設定されているビットに応じて、キー交換アルゴリズムが使用されます。
鍵暗号化を使用する場合：
- クライアントとサーバーは、サポートされている暗号スイートを交換し、共通の暗号（両方でサポートされています）に同意します。
- クライアントは、選択したアルゴリズムとパラメーターを使用して対称鍵を生成し、サーバーの公開鍵で暗号化します（非対称暗号化、RSAまたはECCなど）。
- サーバーはその秘密鍵を使用して鍵を復号化し、この鍵はセッションを保護するために使用されます。ここではDHは関与していません。
Diffie-Hellman（鍵合意）の場合、当事者は共通の素数pとジェネレーター番号gを共有し、両方の当事者がこれらの値に同意する必要があるため、誰が開始するかには大きな違いはありません。 。これらの数は公に合意することができます。したがって、合意開始者はプロトコルのメッセージ構文の問題にすぎません。
その後、次のプロセスが発生します（これは明確に定義されています）。
- クライアントは、DH公開鍵をサーバーに送信します。
- サーバーは、秘密鍵とクライアントの公開鍵に含まれている情報を使用して、秘密のセッション鍵を計算します。
- サーバーは、DH公開鍵をクライアントに送信します。
- クライアントは、秘密鍵とサーバーの公開鍵に含まれている情報を使用して、秘密のセッション鍵を計算します。
- これで、両方の当事者が同じセッションキーを持ち、データの暗号化と復号化に使用できます。これに必要な手順は、次の手順に示されています。
詳細なDH鍵交換アルゴリズムは RFC2631 で説明されています。