TLS 握手过滤在做什么
tls.handshake.type 按握手消息类型筛选：1 是客户端问候、2 是服务端问候、11 是证书、16 是客户端密钥交换。排查 HTTPS 连不上或握手失败时，先确认这几类消息是否按顺序出现，就能快速判断卡在哪一步：只有客户端问候说明服务端没有回应，出现致命告警说明协商参数不被接受。需要注意字段前缀在旧版本里是 ssl. 而不是 tls.，且 TLS 1.3 把大部分握手消息放进加密记录，不看密钥日志就只能看到前两条。
基本信息
| 字段名 | tls.handshake.type（旧版本为 ssl.handshake.type） |
|---|---|
| 常见取值 | 1 客户端问候、2 服务端问候、11 证书、16 客户端密钥交换 |
| 告警消息 | tls.alert_message 及其级别字段 |
| 版本发现 | tls.handshake.extensions.supported_version |
| 前提 | 仅对能识别为 TLS 的流量生效，非标端口需先指定解码方式 |
典型使用场景
- 判断握手卡在哪一步：逐条筛客户端问候与服务端问候
- 确认证书是否送达：TLS 1.2 下可以直接筛出证书消息
- 排查协商失败：筛致命告警，看是协议版本还是加密套件不被接受
- 核对客户端支持的版本与套件：查看客户端问候的扩展字段
- 确认是否为 TLS 1.3：加密握手消息占比高、可见消息很少
常用示例
常用示例
tls.handshake.type == 1 # 客户端问候
tls.handshake.type == 2 # 服务端问候
tls.handshake.type == 11 # 证书（TLS 1.2 明文可见）
tls.handshake.type == 1 || tls.handshake.type == 2 # 只看握手前两步
tls.alert_message && tls.alert_message.level == 2 # 致命告警
tls.handshake.extensions.supported_version # 看版本扩展
tls.handshake.type == 1 && ip.dst == 10.0.0.20 # 某服务端的握手请求握手消息类型对照
| 取值 | 消息 | 判读要点 |
|---|---|---|
| 1 | 客户端问候 | 列出支持的版本与套件，握手从这里开始 |
| 2 | 服务端问候 | 选定版本与套件，缺失说明服务端没有回应 |
| 11 | 证书 | TLS 1.2 明文可见，用于核对证书链 |
| 12 | 服务端密钥交换 | TLS 1.2 下的密钥参数，TLS 1.3 已不可见 |
| 16 | 客户端密钥交换 | 客户端提交密钥参数，之后开始加密通信 |
| 2 级别告警 | 致命告警 | 协商失败或证书校验不通过时会看到 |
只有客户端问候而没有服务端问候，是最常见的握手失败形态。此时要区分是服务端没有收到、还是收到后没有回应，两端同时抓包对照是唯一可靠的判断方式。
TLS 1.3 的证书与密钥交换位于加密记录内，看不到属于正常现象，需要客户端导出密钥日志才能解密查看。不要因为看不到证书就判定证书有问题。
与传输层配合
与传输层配合
tls.handshake.type == 1 && tcp.analysis.retransmission # 握手报文是否被重传
tls.handshake.type == 1 && tcp.stream == 5 # 锁定某条连接的握手
tls.handshake.type == 2 && frame.time_relative < 5 # 前五秒内是否收到服务端问候判读要点
- 握手成功但业务失败时，问题多半在证书校验或应用层协议，不再是握手阶段
- 致命告警里协议版本类错误通常出现在客户端过旧或服务端策略收紧之后
- 握手耗时明显偏长时先看重传，再核对是否为证书链过大导致分段传输
- 同一服务端只有部分客户端握手失败，优先怀疑客户端的协议支持范围