客户端Hello消息详解
TLS握手的第一步，就是客户端发出一条ClientHello。说白了，它就是客户端在跟服务器说：
「嘿，我想跟你建立安全连接。我支持这些版本、这些密码套件、这些扩展……你挑一个吧。」
这条消息看起来简单，但里面藏着大量导致握手失败的坑。我调试过的线上问题里，至少有一半的根因都能追溯到ClientHello的某个字段异常。今天就把它彻底扒开看看。
ClientHello 的核心字段
一条标准的ClientHello，大概长这样（我用Wireshark抓过无数次）：
Handshake Protocol: ClientHello
Version: TLS 1.2 (0x0303)
Random: 32字节随机数
Session ID: 可为空或复用会话ID
Cipher Suites: 支持的一系列密码套件
Compression Methods: 通常只有00(null)
Extensions: 一堆扩展（SNI、ALPN、Supported Groups等）这几个字段，每一个都可能成为故障点。我一个个说。
版本号字段
客户端声明的版本号，实际上是个「心愿版本」。比如TLS 1.2的版本号是0x0303，TLS 1.3是0x0304。但注意——客户端可能会在Supported Versions扩展里列出它真正支持的所有版本。而这里的Version字段，很多时候只是「最旧兼容版本」。
随机数字段
32字节，前4字节是客户端系统时间（Unix时间戳），后面28字节是随机数。这个随机数有两个作用：
- 防重放攻击——因为每次握手随机数都不同
- 参与密钥派生——最终的主密钥（Master Secret）会用到它
随机数本身很少出错，但有个容易被忽略的点：如果客户端时钟严重偏差（比如差了好几年），某些服务器会认为这是重放攻击而拒绝。我见过一台NTP坏掉的IoT设备，时间停在2015年，连2023年的服务器，每次ClientHello都被丢掉。
密码套件列表
这是ClientHello里最核心、也最容易出问题的字段。客户端按优先顺序列出它支持的套件。比如：
Cipher Suites (5 suites)
TLS_AES_256_GCM_SHA384 (0x1302)
TLS_CHACHA20_POLY1305_SHA256 (0x1303)
TLS_AES_128_GCM_SHA256 (0x1301)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc02b)如果列表里没有一个套件是服务器支持的，握手就会在ServerHello阶段失败——但失败信息往往很不明确。实际项目中，我遇到过两种情况最频繁：
- 客户端只发了TLS 1.3套件，服务器只支持TLS 1.2——协商失败
- 客户端误把0x00开头的SSLv2套件混进来——某些库会直接报错
会话ID与会话复用
如果客户端曾经和这个服务器握手过，它会带上之前的Session ID，试图恢复会话。这样可以节省一次完整的握手。但Session ID字段长度可变，如果客户端发的ID是0长度（表示新会话），那没问题。但如果发了一个非法值（比如超过32字节），有些服务器会直接断开连接。
扩展字段
现在的ClientHello里，扩展已经是重头戏了。常见的有：
| 扩展名 | 类型值 | 作用 |
|---|---|---|
| SNI (Server Name Indication) | 0x0000 | 告诉服务器要连接哪个域名（用于虚拟主机） |
| ALPN (Application-Layer Protocol Negotiation) | 0x0010 | 协商上层协议，如HTTP/2、HTTP/1.1 |
| Supported Groups | 0x000a | 列出支持的椭圆曲线或DH群组 |
| Key Share | 0x0033 | TLS 1.3中提前发送密钥交换参数 |
| Signature Algorithms | 0x000d | 告诉服务器客户端支持的签名算法 |
扩展的排列顺序也很讲究。我见过一个案例：某款负载均衡器只解析前几个扩展，如果ALPN排在后面，它就会忽略，导致HTTP/2协商失败。后来我们把ALPN调到扩展列表第一位，问题解决。
ClientHello 与密码故障的典型关联
握手失败很多时候不是协议版本不匹配，而是密码套件或扩展的细节出了问题。我整理了几个常见模式：
- 密码套件列表为空或只有不安全的套件：服务器策略拒绝，浏览器直接显示“ERR_SSL_VERSION_OR_CIPHER_MISMATCH”
- Supported Groups里缺少服务器所需的曲线：比如客户端只发了P-256，服务器期望P-384，协商失败
- Signature Algorithms里没有服务器证书对应的签名算法：比如服务器证书用SHA256WithRSA，但客户端只列了ECDSA算法，握手在CertificateVerify阶段挂掉
- SNI字段为空或格式错误：服务器没有默认证书，直接报错
一张图看懂 ClientHello 结构
下面这张SVG图，把ClientHello的核心字段和可能出问题的节点标出来了。你可以把它贴在调试笔记里：
调试 ClientHello 的三板斧
当你遇到握手失败，又怀疑是客户端的问题时，我建议按这个顺序排查：
- 抓包看原始字节——用Wireshark或tcpdump把ClientHello的整个二进制dump出来，对照RFC检查每个字段长度和值
- 检查密码套件交集——把客户端支持的套件列表和服务器的策略列表做集合与运算，看看有没有公共元素
- 逐层分析扩展——特别关注SNI是否携带、Supported Groups是否包含服务器需要的曲线、Signature Algorithms是否覆盖服务器证书的算法
嗯，其实还有第四板斧：用OpenSSL的命令行模拟一下。比如：
openssl s_client -connect example.com:443 -tls1_2 -cipher 'ECDHE-RSA-AES128-GCM-SHA256'
如果这条命令能成功，但你的应用不行，那问题大概率在代码里。如果这条命令也不行，那问题在网络层或服务器配置上。我一般先用这个快速定位责任方。
总之，ClientHello就是一个TLS握手的「自我介绍」。你的客户端把自己支持的能力都写在里面，服务器从这个列表里挑一个它也觉得OK的组合。如果双方能力交集为空，握手就挂了。理解每个字段的含义，你就能在日志里一眼看出问题出在哪——而不是对着一个handshake failure字样发呆。