在他的博客文章“ HTTPS 连接的前几毫秒”中，Jeff Moser 出色地完成了 TLS/SSL 握手过程，并解释了客户端发生了什么，服务器端发生了什么，以及在该过程的每个步骤中发生了什么。
但是，由于这篇文章是在 2009 年写的，这篇文章描述了使用 TLS 1.0 和 TLS_RSA_WITH_RC4_128_MD5 密码套件的过程。当然，现在认为带有此密码套件的 TLS 1.0 已被弃用。
我有兴趣看到基于 SSL/TLS 协议和密码套件的类似演练，这些协议和密码套件在今天被认为是安全的（最好具有完美的前向保密） - 例如带有 TLS_ECHDE_RSA_WITH_AES_128_GCM_SHA256 的 TLS 1.2。这里有人有兴趣尝试写一篇吗？
免责声明：我不是专业的密码学家，也不是该主题的专家，只是一名安全爱好者。因此，我强烈鼓励任何更有资格的人改进这篇文章。
在我们开始之前，我假设您的意思是“ TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256”（ 0xC0,0x2F）。
因此，根据您发表的文章，这里与 TLS1.0 相比会发生什么变化。
[客户端] ClientHello
首先要做的事情：协议版本应该是 1.2 (0x0303) 并且客户端指定以下参数：
请参阅下面的 ClientHello 数据包捕获 (Firefox 51 Nightly)。
⚠ 一些扩展参数没有展开，因为空/不相关。
[服务器] ServerHello
服务器选择其首选密码套件（TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256）和点格式（未压缩（0），因为它被列为首选）并将其发送回客户端。
[服务器] 证书
服务器返回它的 RSA 证书，这里没有任何变化。服务器身份验证过程与您的文章中详述的过程相同。
[服务器] 服务器密钥交换
服务器发送曲线类型 ( named_curve )、选定的命名曲线 ( secp384r1 )、其临时公钥 ( 04:31:b9:9d:bc:66... ) 以及选定的散列和签名算法。
签名定义为：
SHA-256(ClientHello.random + ServerHello.random + ServerKeyExchange.params);
并由服务器的私钥签名。
曲线secp384r1（也称为NIST 分类下的P-384）是标准曲线，由以下等式定义：
E: y 2 =x 3 +ax+b (mod p)
在素数场 F p-384上具有以下域参数：
所有这些参数都是公开的。
旁注：客户端和服务器都同意使用命名曲线，导致服务器密钥交换数据包更小，因为域参数是标准化的，因此双方都知道。
服务器公钥计算如下：
K pub = K priv × G
服务器私钥只是一个随机数，定义为：
1 ≤ K隐私≤ n-1
[服务器] ServerHelloDone
与 TLS1.0 没有区别。
[客户端] ClientKeyExchange / ChangeCipherSpec
此数据包包含客户端的临时 ECDH 公钥。它的计算方式与服务器的公钥相同（同样，生成器G在客户端和服务器之间是通用的）。
从那时起，客户端通知服务器来自它的下一条消息将被加密。
[服务器] ChangeCipherSpec
服务器通过返回相同的 ChangeCipherSpec 消息来确认客户端的最后一条消息。
除此之外，所有通信都使用 AES-GCM 128 位加密。
通过将自己的私钥乘以对方的公钥来计算双方的对称密钥，即：
截至今天（2016 年 8 月），TLS1.3 仍处于草案阶段，因此深入研究它还为时过早。尽管如此，在 TLS1.3 上编写基于数据包嗅探的类似文章还是很棘手，因为握手有很大不同，如下图所示：
如您所见，嗅探握手序列（使用cloudflare server）不会告诉您太多，因为相关数据在 ServerHello 数据包中加密（请参阅“EncryptedExtension”字段）。
由于尚不支持 TLS 1.3，因此我无法使用 Wireshark 说明序列。
