所以据我了解，它通常是这样工作的：
- 客户端连接到服务器
对于 HTTPS 是的。对于其他应用程序，它会有所不同；有些建立新的连接，有些重用现有的连接。
- 客户端告诉服务器他们支持的协议（例如 TLS 1.2）和密码套件（例如 ECDHE-RSA-AES128-GCM-SHA256）
Ciphersuite的复数形式，以及扩展中的许多其他内容，都显示在您链接的文章中。（突出显示 SNI 与所描述的 IIS/http.sys 逻辑相关。）
- 服务器回答并同意他们都支持的协议和密码套件（例如 TLS 1.2 和 ECDHE-RSA-AES128-GCM-SHA256），以及服务器证书（也包含他们的公钥）
该证书包含静态（长期）公钥，正如 ISMSDEV 所说，伴随着任何中间的又名链证书，以及可选的根证书。该文章没有明确说明，但确实在网络跟踪中显示，证书实际上是单独的消息，但可能在同一个 SSL/TLS记录中并且几乎总是在相同的 TCP 帧中。对于临时密钥交换，如您指定但不是本文中的密码套件，服务器的临时密钥（带有参数和签名，就像 ISMSDEV 所说的那样）在单独的消息 ServerKeyExchange 中；然后可选的另一条消息“请求”客户端证书，同样没有明确说明，这次没有显示；然后是 ServerHelloDone 消息，根本没有描述，但显示了。
--- 现在从这里开始，他们根据选择的协议进行通信，密码套件的作用变得很重要 ---
协议版本/格式和密钥交换已经影响了上面的服务器消息。对称密码和可能的哈希还没有效果。
- 客户端根据已知的证书颁发机构验证服务器的证书并提取服务器的公钥以进行密钥交换
验证证书链，提取长期（已认证）密钥，并提取和验证临时密钥（如果使用），它位于您指定的密码套件中。
- 现在密码套件的密钥交换开始了（在本例中为 ECDHE-RSA），它使用服务器的公钥 - 结果是预主密钥（如下图所示）
密钥交换已经开始，上面有服务器消息；现在使用客户端的密钥完成。您复制的图表显示了一个从客户端到服务器的箭头，带有（加密的）预主密钥，因为它适用于使用 RSA 密钥交换的密码套件，但您使用 ECDHE-RSA 密钥交换指定了一个密码套件，并且为此客户端的临时公钥而是发送（明文），并且在两个对等方独立地使用 ECDH 算法来导出预主密钥。
此外，如果请求了客户端证书（也称为客户端身份验证），则客户端可以通过客户端的密钥交换消息（两者）作为单独的消息发送自己的证书链及其在副本上的签名，如文章中所述，但未显示。
- 使用预主密钥，然后使用密码和散列算法（在本例中为 AES128-GCM 和 SHA256）进行消息加密和摘要。
还没有。
- 重复密钥交换，使用密码加密，使用预先共享的秘密并使用散列算法进行验证。结果是主秘密
没有重复，也没有直接使用前主密。相反，pre-master secret 与 Hello 消息中的“随机”（nonce）值一起使用，在称为 PRF（伪随机函数）的算法中推导出主密钥，然后类似地使用主密钥来推导几个会话密钥。正如文章所说：
[服务器] 执行一系列步骤（客户端也执行，从相同的预主密钥开始）以生成主密钥。(bullet) 客户端和服务器都使用主密钥来生成会话密钥，这些密钥是对称密钥，用于加密和解密 SSL 会话期间交换的信息并验证其完整性 [...]
请注意“会话密钥”中的复数形式。对于TLS1.2 中的某些密码套件，包括您指定的密码套件，密码套件中的哈希会影响 PRF。对于其他密码套件和所有较低的协议版本，它不会。请参阅ECDHE-RSA-AES-GCM-SHA 中的哈希值是什么？.
- 主密钥与密码和散列算法一起使用，以加密任何进一步的通信。
每个端点发送一条消息 ChangeCipherSpec 以“激活”密码套件，然后发送一条消息 Finished，这是第一个加密（和 MACed）消息。正如文章所说：
CLIENT 和 SERVER 互相发送一条消息，通知他们未来的消息将使用会话密钥加密。然后它发送一个单独的（加密的）消息，表明它的握手部分已经完成。
没有任何东西直接使用主密钥。对称（数据）加密使用两个会话密钥（每个方向一个）。对于使用 HMAC 来保证完整性的密码套件（如文章中所述），它使用密码套件中的哈希算法（以及另外两个会话密钥），但是您指定了一个使用 GCM 模式的密码套件，正如 ISMSDEV 所说，它提供了自己的身份验证（不是使用任何哈希）。
（图表来自：https ://blogs.msdn.microsoft.com/kaushal/2013/08/02/ssl-handshake-and-https-bindings-on-iis/ ）