ブラウザでHTTPSのURLを閲覧したことがあれば、SSLハンドシェイクを経験したことがあると思います。
SSLハンドシェイクの主な目的は、サーバとクライアント間の通信でプライバシーとデータの完全性を提供することです。 ハンドシェイクの間、サーバとクライアントは安全な接続を確立するために必要な重要な情報を交換します。
SSLハンドシェイクには片方向SSLと双方向SSL（Mutual SSL）の2種類があり、片方だけでなくもう片方もあります。 この2つの違いは、一方向SSLではクライアントのみがサーバーの身元を確認するのに対し、双方向SSLではサーバーとクライアントの両方が互いの身元を確認することです。 通常、HTTPSのウェブサイトを閲覧する場合、ブラウザ（クライアント）だけがウェブサイト（サーバー）の身元を確認する片方向SSLが使用されています。
SSLハンドシェイクの間、サーバとクライアントは以下のステップを踏みます。 クライアントは HTTPS 接続を開始するために必要な情報を送信します。
上のログでは、クライアントが TLS v1.2 で Hello していることが分かります。 これにより、クライアントはTLSバージョン1.2以下をサポートしていることをサーバーに通知しています。 クライアントがサポートしている暗号のリストも上記のログから確認することができます。 このリストの中から、サーバーはサポートする暗号スイートを選択する。 このリストに、サーバが認識しない、サポートしない、あるいは使用を希望しない暗号スイートが含まれている場合、サーバはそれらの暗号を無視します。 サポートされている暗号スイートが見つからない場合、サーバーは失敗の警告を送信し、接続を終了します。 サーバーHello
サーバーは、クライアントHelloから選択した構成と、ハンドシェイクを進めるための情報を応答して返します。 Server Helloは以下のようになります。
Sever は、Client Helloメッセージでクライアントが提案したバージョンと、サーバーがサポートする最も高いバージョンのどちらか低い方をTLSバージョンとして選択します。
サーバハローとともに、サーバは証明書チェーンとともにサーバの証明書を送信します。
3. サーバ鍵交換メッセージ
このメッセージはサーバからクライアントに送信され、クライアントがプリマスタシークレットを生成するために必要な詳細情報を含んでいます。 このメッセージは、RSA鍵交換アルゴリズム（詳細は後述）や、pre-master secretを生成するためにサーバからの情報を必要としない他の鍵交換アルゴリズムが使用されている場合、送信されることはありません。
Elliptic Curve Diffie Hellman(ECDH) 鍵交換では、サーバのECDH公開鍵に関する以下の詳細がクライアントに送られます。
4. Certificate Request
ここで片方向SSLは双方向SSLから外れることになります。 一方向SSLではクライアントの信頼性は検証されません。
このステップでは、サーバはクライアントから証明書の種類、証明書の署名アルゴリズム、サーバがサポートする認証局を指定した証明書要求を送ります。 認証局リストが空である状況もありえます。 このような場合、クライアントはクライアント証明書を送信するか、または送信しないかを選択できます（クライアントの実装に依存します）
最後に、サーバーはサーバー Hello の終了を示す Server Hello Done メッセージを送出します。 このメッセージの送信後、サーバーはクライアントからの応答を待ちます。
5. クライアント証明書
クライアントはサーバにその証明書チェーンを提示する。
6. Client Key Exchange Message
このメッセージはクライアント証明書メッセージに続いてクライアントから送信される必要があります。 クライアント証明書が(一方向性のSSLで)提示されない場合、クライアント鍵交換メッセージはクライアントがServerHelloDoneメッセージを受け取った後に送信されなければなりません。 計算コストが非対称暗号化よりはるかに低いため、この目的には対称暗号化が使用されます。 対称型暗号を使用するためには、両端間で共通の鍵が必要です。
TLSv1.2仕様では、2つのクライアント鍵交換方式が説明されています。
鍵交換アルゴリズムとしてRSAが使用される場合、クライアントは48バイトのプレマスターシークレットを生成する。 クライアントはこのプレマスターシークレットを証明書の公開鍵で暗号化し、サーバに送信します。
Diffie-Hellmanを使用する場合、クライアントとサーバが同じpre-master secretを生成できるようにDiffie-Hellmanパラメータを送信します。
その後、双方はpre-master secretを使ってmaster secretを生成し、master secretはセッションデータを暗号化する共通鍵の生成に使用します
7. Finished
認証に成功し、pre-master secret/master secret を生成すると、残りの通信が暗号化されることを示す変更暗号仕様メッセージがクライアントとサーバーの両方から送信されます。
変更暗号仕様メッセージのすぐ後に Finished メッセージが送信されます。 これはネゴシエートされたアルゴリズムで暗号化された最初のメッセージとなります。 アプリケーションデータは，両者がFinishedメッセージを送信し，メッセージの内容を確認した後，転送されます。
https://tools.ietf.org/html/rfc5246
https://docs.microsoft.com/en-us/windows/desktop/secauthn/cipher-suites-in-schannel
https://www.websecurity.symantec.com/security-topics/what-is-ssl-tls-https
https://docs.apigee.com/api-platform/system-administration/keystores-and-truststores
https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman
https://www.globalsign.com/en/ssl-information-center/what-are-certification-authorities-trust-hierarchies/
https://www.geeksforgeeks.org/rsa-algorithm-cryptography/
https://www.acunetix.com/blog/articles/establishing-tls-ssl-connection-part-5/