2. TLS协议核心机制精讲
做TLS指纹与加密流量威胁检测，第一步不是抓包，而是弄清楚“哪些字段在明文里、哪些字段被加密、哪些字段会随客户端实现而变化”。TLS协议本身是分层的：握手层负责协商参数与建立密钥，记录层负责把上层数据切成记录并加密传输。检测视角下，我们真正能稳定观测的，主要是握手阶段的明文消息、记录层头部，以及部分扩展字段。理解这些可观测点，才能把“指纹”落到具体字节上。
握手流程：明文协商与密钥确认
以TLS 1.2的完整握手为例，客户端先发ClientHello，携带版本、随机数、会话ID、密码套件列表和扩展；服务端回ServerHello，选定版本、随机数、会话ID和单个密码套件，随后发送Certificate、ServerKeyExchange（视密钥交换算法而定）、ServerHelloDone。客户端再发ClientKeyExchange、ChangeCipherSpec和Finished，服务端回ChangeCipherSpec和Finished。TLS 1.3把密钥交换前移，ServerHello之后的大部分握手消息已被加密，能看到的明文显著减少，这也是TLS 1.3指纹更难提取的根本原因。
从检测角度看，ClientHello是信息密度最高的报文：它包含客户端支持的版本、密码套件顺序、扩展顺序、椭圆曲线列表、签名算法列表、SNI、ALPN等。不同客户端库（浏览器、curl、Python requests、Go net/http、Java、移动端SDK）在这些字段的组合与顺序上存在稳定差异，这正是JA3/JA4类指纹的基础。
记录层结构：五个字节的头部决定解析起点
记录层是TLS的传输封装。每条记录由5字节头部开始：ContentType（1字节）、ProtocolVersion（2字节）、Length（2字节），随后是长度对应的载荷。ContentType常见取值：20为ChangeCipherSpec，21为Alert，22为Handshake，23为ApplicationData。检测时，记录层头部是少数始终明文的字段，但要注意两点：一是TLS 1.3中记录层version通常固定为0x0303，不能据此判断真实版本；二是握手消息可以跨多条记录，也可以一条记录里放多个握手消息，解析时必须按Length循环读取并做握手消息重组。
实际抓包中，如果看到ContentType=22且载荷前几字节为0x01，说明是ClientHello；0x02是ServerHello；0x0b是Certificate；0x10是ClientKeyExchange。这些类型值配合记录长度、消息长度，可以快速定位指纹字段的偏移。
扩展字段：指纹差异最集中的区域
ClientHello的扩展是一段TLV序列：2字节扩展类型、2字节长度、变长数据。常见扩展包括server_name（0）、supported_groups（10）、ec_point_formats（11）、signature_algorithms（13）、ALPN（16）、supported_versions（43）、key_share（51）、psk_key_exchange_modes（45）、padding（21）等。不同客户端不仅支持的扩展集合不同，扩展的排列顺序也高度稳定。JA3的做法是把ClientHello的版本、密码套件、扩展类型列表、椭圆曲线、椭圆曲线点格式按固定规则拼接后做MD5；JA4则进一步引入扩展顺序、ALPN、SNI存在性等维度，抗伪造能力更强。
需要特别注意的是GREASE机制：Chrome等浏览器会随机插入保留值（如0x0a0a、0x1a1a）来防止服务端固化行为。做指纹时通常要过滤这些GREASE值，否则同一客户端每次握手都会得到不同指纹。
版本协商与会话恢复
版本协商在ClientHello的legacy_version和supported_versions扩展中同时出现。TLS 1.3客户端通常把legacy_version写成0x0303，真实版本放在supported_versions里。服务端在ServerHello中通过supported_versions确认最终版本。检测时若只看记录层version，会把1.3误判为1.2。
会话恢复分为两种：TLS 1.2的Session ID/ Session Ticket恢复，以及TLS 1.3的PSK恢复。恢复握手中，ClientHello会携带pre_shared_key扩展或非空session_id，服务端若接受则跳过证书与密钥交换，握手消息数量明显减少。对检测而言，恢复握手缺少Certificate消息，若仍按完整握手模板解析会出错；同时，恢复握手的ClientHello扩展集合也可能与首次不同，指纹需要区分“首次”与“恢复”两种上下文。
密钥交换：从RSA到ECDHE再到1.3的key_share
TLS 1.2中，若选用ECDHE套件，ServerKeyExchange会携带命名曲线、公钥和签名；客户端在ClientKeyExchange中回送自己的公钥。TLS 1.3把密钥交换参数放进key_share扩展，客户端在ClientHello里直接带上自己的公钥，服务端在ServerHello里回送选定组和公钥，从而把往返压缩到一次。检测时，supported_groups和key_share中的组ID（如x25519=29、secp256r1=23）是区分客户端实现的重要特征。
可直接使用的ClientHello可观测字段清单
| 层级 | 字段 | 典型取值/说明 | 检测用途 |
|---|---|---|---|
| 记录层 | ContentType | 22=Handshake | 定位握手记录 |
| 记录层 | ProtocolVersion | 0x0301/0x0303 | 辅助判断，1.3下不可靠 |
| 记录层 | Length | 变长 | 循环读取与重组 |
| 握手层 | HandshakeType | 1=ClientHello | 识别消息类型 |
| 握手层 | legacy_version | 0x0303 | 兼容字段 |
| 握手层 | CipherSuites | 如0x1301、0xc02b | JA3/JA4输入 |
| 扩展 | server_name | SNI域名 | 域名与指纹关联 |
| 扩展 | supported_versions | 0x0304=1.3 | 真实版本判断 |
| 扩展 | supported_groups | 29=x25519 | 密钥交换能力 |
| 扩展 | signature_algorithms | 0x0403=ecdsa_secp256r1_sha256 | 客户端栈特征 |
| 扩展 | ALPN | h2、http/1.1 | 应用层协议指纹 |
| 扩展 | key_share | 组ID+公钥 | 1.3密钥交换 |
把上述字段落到代码里，解析逻辑大致如下（示意，非完整实现）：
# 伪代码：从ClientHello记录中提取可观测字段
def parse_client_hello(payload):
# payload 已去掉5字节记录头
hs_type = payload[0] # 应为 0x01
hs_len = int.from_bytes(payload[1:4], 'big')
body = payload[4:4+hs_len]
legacy_version = body[0:2] # 通常 0x0303
random = body[2:34]
sid_len = body[34]
sid = body[35:35+sid_len]
cs_len = int.from_bytes(body[35+sid_len:37+sid_len], 'big')
cipher_suites = body[37+sid_len:37+sid_len+cs_len]
# 继续解析压缩方法、扩展长度、扩展TLV
return legacy_version, cipher_suites, sid这段代码的关键不是语法，而是偏移顺序：版本、随机数、会话ID、套件、压缩方法、扩展。任何一步长度读错，后面的扩展都会错位，指纹自然失真。实际工程中建议用成熟解析库（如scapy、tshark字段导出、ja3库）做交叉验证，再针对GREASE和会话恢复做归一化处理。
本节的核心结论是：TLS指纹不是“抓一个包算个哈希”，而是对握手明文结构、记录层边界、扩展顺序和版本协商语义的系统性理解。只有把可观测字段的层级、偏移和变化条件弄清楚，后续的指纹提取、流量分类和威胁检测才有可靠基础。