1.1.1 扩展消息
后面是扩展部分的分析，每个扩展一般都包含类型（Type）、长度（Length）和数据（Data）三个部分。
1.1.1.1 Reserved
Reserved：预留位置，为空。
1.1.1.2 status_request
status_request：状态请求，允许客户端在 TLS 握手期间，向服务器请求其证书的吊销状态信息。这样客户端就无需在握手完成后自己去在线查询。消息结构如下图所示：
消息详解：
Extension: status_request (len=5)
Type: status_request (5) # 扩展类型代码为 5
Length: 5 # 此扩展内容的总长度为 5 字节
Certificate Status Type: OCSP (1) # 请求的状态类型为 OCSP
Responder ID list Length: 0 # 客户端未指定首选的 OCSP 响应器列表
Request Extensions Length: 0 # 客户端未包含额外的请求扩展
逻辑流程图
1.1.1.3 signed_certificate_timestamp
signed_certificate_timestamp ：签名证书时间戳，客户端使用此扩展来向服务器表明，它希望在握手期间收到服务器证书的 CT 证明（即 SCT证书透明度）。
Extension: signed_certificate_timestamp (len=0)
Type: signed_certificate_timestamp (18) # 扩展类型码为 18，表示这是 CT 扩展
Length: 0 # 扩展内容长度为 0，表示客户端在 ClientHello 消息的此扩展中，没有携带任何数据。
1) 什么是 CT？
CT 是一项旨在监测和审计 HTTPS 证书生态系统的技术。它解决了以下问题：
误签发证书：证书颁发机构（CA）可能会因为内部问题或被黑客攻击，错误地为一个不属于申请者的域名签发证书。
恶意证书：某些 CA 可能受政府或其他组织压力，签发不当证书。 CT 通过一个公共的、只能追加的日志系统来记录所有颁发的证书，使得任何感兴趣的人都可以审查证书的颁发记录，从而及时发现可疑证书。
2) 什么是 SCT？
当 CA 签发一个证书时，它可以向一个或多个 CT 日志服务器 “提交”该证书。
CT 日志服务器在将该证书纳入公共日志后，会返回一个签名证书时间戳（SCT）。这个 SCT 就是一个“收据”，证明该证书已被记录在案，并且记录于某个特定时间。
SCT 可以通过三种方式交付给客户端：
通过 TLS 扩展：在 server hello或 EncryptedExtensions中附带一个 signed_certificate_timestamp 扩展，里面包含 SCT 列表。
嵌入到证书中：作为一个 X.509 证书扩展。
通过 OCSP Stapling：在 OCSP 响应中包含 SCT。
1.1.1.4 Key_share
Key_share ： 密钥共享，在握手的第一条消息 (ClientHello) 中，客户端直接发送一个或多个密钥交换信息，从而将传统的“Hello”和“密钥交换”两个步骤合二为一，实现了 1-RTT（一次往返）完整握手。这取代了 TLS 1.2 中的 RSA 密钥交换或静态 DH 交换。结构如下图：
Extension: key_share (len=1263) # 整个扩展长度1263字节
Type: key_share (51) # 扩展类型码51
Length: 1263 # 扩展数据总长度
Key Share extension
Client Key Share Length: 1261 # 客户端密钥共享数据长度
Key Share Entry: Group: Reserved (GREASE), Key Exchange length: 1
Group: Reserved (GREASE) (10794) # GREASE 抗干扰组
Key Exchange Length: 1
Key Exchange: 00 # 占位符值
Key Share Entry: Group: X25519MLKEM768, Key Exchange length: 1216
Group: X25519MLKEM768 (4588) # **后量子混合算法**
Key Exchange Length: 1216 # 密钥交换数据非常大（PQ特性）
Key Exchange […]: 6c90a5...15b # 具体的后量子+经典密钥交换数据
Key Share Entry: Group: x25519, Key Exchange length: 32
Group: x25519 (29) # **经典算法（椭圆曲线）**
Key Exchange Length: 32 # 密钥交换数据很小（经典算法特性）
Key Exchange: c8c361...7657 # 具体的经典算法密钥交换数据
TLS 1.3协议客户端在第一次问候中就“猜测”服务器可能支持的密钥交换算法（如 x25519），并直接生成密钥对，将公钥部分（即 Key Exchange 数据）发送给服务器。服务器收到后，可以直接使用对应的算法生成共享密钥，大大加快了握手速度。
基于 key_share 扩展的密钥交换流程
----------------------------------------额外的知识-----------------------------------------------
算法详解
x25519 (Group 29)：
类型：经典椭圆曲线密钥交换（ECDH）。
特点：目前最安全、最高效的经典密钥交换算法之一。密钥数据仅需 32 字节，安全性高，计算速度快。这是当前互联网的主流和默认选择。
X25519MLKEM768 (Group 4588)：
类型：后量子密码学（PQC）混合密钥交换。
构成：这个名字表明它是一个“混合”构造。
X25519：代表它包含了经典的 X25519 算法。
ML-KEM：是 Module-Lattice-based Key Encapsulation Mechanism 的缩写，即基于模格的密钥封装机制。这就是被 NIST 选为标准化的 CRYSTALS-Kyber 算法。
768：代表其安全等级（相当于 AES-192 的等级）。
特点：密钥交换数据非常大（1216 字节），这是基于格的后量子算法的典型特征。它同时提供了经典安全性和后量子安全性。即使未来量子计算机攻破了 X25519，ML-KEM 部分仍然能保证安全。
GREASE 机制
Group: Reserved (GREASE) (10794)：
目的：抗干扰。客户端随机地插入一些保留的、无意义的组ID和数据。
作用：确保服务器和网络中间设备（如防火墙）能够正确地处理它们不认识的算法组。这有助于防止某些网络设备因为实现僵化而错误地阻止包含新算法的 TLS 连接，为未来引入新算法（如 PQC 算法）铺平道路。
------------------------------------------------------------------------------------------------------
简单来说，这个 key_share 扩展就是客户端对服务器说：“这是我支持的几种密钥交换方式（包括面向未来的后量子方式），我连公钥都准备好了。请你选一种你支持的，然后我们立刻就能算出密钥开始加密通信。”
)
