SSL / TLS接続における選択された暗号スイートの役割
安全なTLS構成（HTTPSなど）の場合、トピックは主にサポートされている暗号スイートについてです。
暗号スイートのどの部分がSSL/TLS接続でどの役割を持つかを完全に理解したいと思います。
だから私が理解していることから、それは一般的に次のように機能します：
- クライアントがサーバーに接続する
- クライアントは、サポートされているプロトコル（TLS 1.2など）と暗号スイート（例ECDHE-RSA-AES128-GCM-SHA256）についてサーバーに通知します
- サーバーが応答し、両方がサポートするプロトコルと暗号スイート（TLS 1.2＆ECDHE-RSA-AES128-GCM-SHA256）、およびサーバー証明書（公開鍵も含む）に同意する
---ここからは、選択したプロトコルに基づいて通信し、暗号スイートの役割が重要になります---
クライアントはサーバーの証明書を既知の認証局と照合して検証し、鍵交換のためにサーバーの公開鍵を抽出します
これで、暗号スイートの鍵交換が開始され（この場合はECDHE-RSA）、サーバーの公開鍵が使用されます-結果はpre-master secret（下図に示すとおり）
プリマスターシークレットを使用すると、暗号化アルゴリズムとハッシュアルゴリズムの両方が使用されます（この場合はAES128-GCMおよびSHA256）メッセージの暗号化とダイジェスト。
鍵交換が繰り返され、事前共有秘密を使用して暗号で暗号化され、ハッシュアルゴリズムで検証されます。結果はマスターシークレットです
master secretは、暗号化およびハッシュアルゴリズムとともに使用され、それ以降の通信を暗号化します。
（図の例： https://blogs.msdn.Microsoft.com/kaushal/2013/08/02/ssl-handshake-and-https-bindings-on-iis/ ）
TLS通信におけるciphersuiteの役割についての私の理解は正しいですか-または、いくつかの詳細について間違っていますか？
だから私が理解していることから、それは一般的に次のように機能します：
- クライアントがサーバーに接続する
HTTPSの場合はい。他のアプリケーションでは異なります。新しい接続を作成するものと、既存の接続を再利用するものがあります。
- クライアントは、サポートされているプロトコル（TLS 1.2など）および暗号スイート（ECDHE-RSA-AES128-GCM-SHA256など）についてサーバーに通知します
Ciphersuites複数形、および拡張機能の他のかなりの数の両方が、リンクしている記事に示されています。 （説明されているIIS/http.sysロジックに関連するものとしてSNIを強調しています）
- サーバーは、両方がサポートするプロトコルと暗号スイート（TLS 1.2およびECDHE-RSA-AES128-GCM-SHA256など）とサーバー証明書（公開鍵も含む）に応答して同意します。
証明書にはstatic（長期）公開鍵が含まれており、ISMSDEVが言うように、中間の別名チェーン証明書、およびオプションでルート証明書が付属しています。記事には明確には記載されていませんが、ネットワークトレースでは、証明書は実際には別個のメッセージですが、同じSSL/TLSrecordとほとんどの場合、同じTCPフレーム内にあります。指定した暗号スイートのように一時的なキー交換の場合、記事に記載されているものではなく、サーバーの一時キー（ISMSDEVが言ったように、パラメータとシグネチャを含む）は別のメッセージServerKeyExchangeにあります。次に、オプションでクライアント証明書を「要求」する別のメッセージ、再度明確に述べられていませんが、今回は表示されていません。次に、ServerHelloDoneメッセージ、示されている以外はすべて。
---ここからは、選択したプロトコルに基づいて通信し、暗号スイートの役割が重要になります---
プロトコルのバージョン/フォーマットとキー交換は、すでに上記のサーバーメッセージに影響を与えています。対称暗号とおそらくハッシュはまだ効果がありません。
- クライアントはサーバーの証明書を既知の認証局と照合して検証し、鍵交換のためにサーバーの公開鍵を抽出します
証明書チェーンを検証し、長期（証明済み）鍵を抽出します。また、指定した暗号スイートにある一時鍵を使用している場合はそれを抽出して検証します。
- これで、暗号スイートの鍵交換が開始され（この場合はECDHE-RSA）、サーバーの公開鍵が使用されます-結果はプレマスターシークレットです（下の図に示されています）。
上記のサーバーメッセージを使用して、鍵交換がすでに開始されています。これで、クライアントのキーを使用してcompletedになりました。コピーした図は、クライアントからサーバーへの矢印を示しています。これは、（暗号化された）プリマスターシークレットがRSA鍵交換を使用する暗号スイート用であるが、ECDHE-RSA鍵交換を使用する暗号スイートを指定し、そのためにクライアントの一時的な公開鍵を使用しているためです代わりに（平文で）送信され、両方のピアで独立してECDHアルゴリズムが使用されて、プリマスターシークレットが導出されます。
さらに、クライアント証明書（別名クライアント認証）が要求された場合、クライアントは独自の証明書チェーンとその署名をトランスクリプトにクライアントの鍵交換メッセージ（両方）として送信できます。記事に記載されているが示されていない個別のメッセージ。
- プリマスターシークレットを使用すると、メッセージの暗号化とダイジェストに暗号とハッシュアルゴリズム（この場合はAES128-GCMとSHA256）の両方が使用されます。
未だに。
- 鍵交換が繰り返され、事前共有秘密を使用して暗号で暗号化され、ハッシュアルゴリズムで検証されます。結果はマスターシークレットです
何も繰り返されず、プリマスターシークレットを直接使用するものはありません。代わりに、プリマスターシークレットは、PRF（疑似ランダム関数）と呼ばれるアルゴリズムでHelloメッセージからの「ランダム」（ノンス）値とともに使用され、マスターシークレットを導出します。次に、マスターシークレットを使用してseveralセッションキー。記事が言うように：
[サーバー]は一連のステップを実行して（クライアントも同じプレマスターシークレットから開始して）マスターシークレットを生成します。 （箇条書き）クライアントとサーバーの両方がマスターシークレットを使用してセッションキーを生成します。セッションキーは、SSLセッション中に交換される情報の暗号化と復号化、およびその整合性の検証に使用される対称キーです[....]
「セッションキー」の複数形に注意してください。指定したものを含むTLS1.2のsome暗号スイートの場合、暗号スイートのハッシュはPRFに影響します。他の暗号スイートおよびそれより下位のすべてのプロトコルバージョンでは、そうではありません。 ECDHE-RSA-AES-GCM-SHAのハッシュは何ですか？ を参照してください。
- マスターシークレットは、暗号およびハッシュアルゴリズムと共に使用され、それ以降の通信を暗号化します。
各エンドポイントは、メッセージChangeCipherSpecを送信して暗号スイートを「アクティブ化」し、次にメッセージを送信します。これは、最初の暗号化（およびMACed）メッセージです。記事が言うように：
クライアントとサーバーは、今後のメッセージがセッションキーで暗号化されることを通知するメッセージを互いに送信します。次に、ハンドシェイクの一部が終了したことを示す別の（暗号化された）メッセージを送信します。
マスターキーを直接使用するものはありません。対称（データ）暗号化では、2つのセッションキー（各方向に1つ）を使用します。 （記事のように）整合性のためにHMACを使用する暗号スイートでは、暗号スイート（および2つ以上のセッションキー）からのハッシュアルゴリズムを使用しますが、ISMDEVが独自の認証を提供するGCMモードを使用する暗号スイートを指定しました（ anyハッシュを使用）。
正しい方向に進んでいると思います。プロトコルへの暗号スイートの影響に関するプロトコルについての私の理解は、それ自体です。
クライアントこんにちは
クライアントがサポートするSSL/TLSバージョンの最高バージョン、クライアントによって生成されたランダムなナンス、セッションID（初期ハンドシェイクはゼロになる）、クライアントがサポートする可能な暗号スイート（以下を参照）のリスト（これらには、使用する認証アルゴリズム、使用する暗号化アルゴリズム、および鍵合意プロトコル）
クライアントはサーバーからの応答を待ちます...
サーバーhello
クライアントがサポートするサーバーがサポートするSSL/TLSの最高バージョン、サーバーが生成するランダムなナンス、クライアントが提供するセッションID、またはクライアントが提供しない場合は新しいセッションIDが含まれます。サーバーは、使用する暗号スイートを選択します。次に例を示します。
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
これは次のように分類されます。
-プロトコル-TLS
-鍵交換アルゴリズム-ECDHE_RSA-RSAを使用した楕円曲線Diffie Helman Ephemeral。クライアントが対称鍵に同意する方法。
-暗号化アルゴリズム-AES_128_GCM-合意されたキーでペイロードデータを暗号化するために使用されるアルゴリズム。 AES 128（鍵長128ビットのAdvanced Encryption Standard）およびブロックモードGCM（Galois/Counter Mode）を使用し、暗号化されたデータへのメッセージ認証も提供します。
-擬似ランダム関数-SHA256-マスターシークレットの生成に使用されるアルゴリズムのタイプ。これは、セッションキーの作成のシードに使用されます。この暗号スイートでは、有名なSHA256ハッシュアルゴリズムを使用して、高レベルのエントロピーを提供しています。証書
このメッセージには、サーバーの公開鍵の署名に使用される証明書と、X509証明書チェーン内の中間証明書があります。
サーバーキー交換
暗号スイートの鍵合意プロトコルを使用して、サーバーは必要な要素をクライアントに送信します。たとえば、Ephermeral Diffie Helmanの場合、これは3つのパラメーターとそれらのパラメーターの署名になります。パラメータは、2つのグローバルDHパラメータとサーバーDH公開鍵です。