【密评实战】服务端“挑战-响应”身份鉴别：从签名提取到验签的完整验证路径

1. 挑战-响应机制的核心原理

"挑战-响应"就像古代城门守卫的暗号验证——守卫给出随机谜题（挑战），来者必须用特定方式解答（响应）才能证明身份。在密码学中，这个过程通过数字签名实现双向认证。我去年参与某政务云项目时，就曾因忽略响应报文中的时间戳验证，导致系统遭受重放攻击。下面用实际抓包数据还原完整流程：

服务端身份鉴别的核心在于验证三个要素：

1. 签名有效性：确认响应数据确实由合法服务端签发
2. 随机数唯一性：防止重放攻击的关键屏障
3. 证书链可信度：确保证书颁发机构在可信列表内

典型TLS握手过程中，服务端会在ServerKeyExchange消息携带签名值。用Wireshark抓包可以看到这样的结构：

hex复制Signature Algorithm: ecdsa_secp256r1_sha256
Signature: 3045022100e4795b5a947526f8e7cbd0edd571ea8749e0efd24323799346ea2c740c006c5a0220026189e51c19d20d40a82606d0ed72cb9530a189bbb94c09e4559d7d8ff3f598

2. 签名值提取实战技巧

在真实网络环境中提取签名值，就像在混杂的快递仓库里找特定包裹。推荐三种我常用的提取方式：

2.1 Wireshark自动解析法

1. 过滤TLS握手报文：tls.handshake.type == 12
2. 右键报文 → Follow → TLS Stream
3. 在ServerKeyExchange消息中找到Signature字段

2.2 十六进制手动定位

当工具解析失败时（比如非标准端口通信），需要手动定位特征值：

• ECDSA签名开头通常是30 45（ASN.1 SEQUENCE标识）
• 用010 Editor打开抓包文件，搜索十六进制模式30 45 02 21

2.3 编程提取示例

用Python的scapy库提取签名值：

python复制from scapy.all import *

pkts = rdpcap("tls.pcap")
for pkt in pkts:
    if pkt.haslayer(TLS) and pkt[TLS].type == 0x0C:
        sig = pkt[TLS].msg[0].sig
        print(f"签名值: {sig.hex()}")

我曾遇到某金融系统使用自定义TLS扩展，常规工具无法解析。最终通过比对RFC文档和十六进制编辑器，发现其签名值偏移量比标准位置后移8字节。

3. 签名原文的拼装艺术

签名原文就像合同正文，任何细微差异都会导致验签失败。根据GM/T 0024标准，完整拼装流程如下：

3.1 随机数提取要点

• 客户端随机数：在ClientHello的random字段（32字节）
• 服务端随机数：在ServerHello的random字段（32字节）

用OpenSSL命令验证：

bash复制openssl s_client -connect example.com:443 -showcerts | grep -A 5 "Random"

3.2 证书提取的陷阱

某次测评中，我发现证书长度字段缺失导致验签失败。正确步骤应该是：

1. 从ServerCertificate消息提取证书（DER格式）
2. 计算证书长度：printf "%06x" $(wc -c < cert.der)
3. 注意长度字段需占3字节（000225表示225字节）

3.3 完整拼装示例

假设已有：

• 客户端随机数：f81ce4d...
• 服务端随机数：5ed8968...
• 证书长度：000225
• 证书内容：308202...

拼装命令：

bash复制echo -n "f81ce4d...5ed8968...000225308202..." | xxd -r -p > sign_origin.bin

记得用-n参数避免自动添加换行符，这个细节曾让我调试了整整两天。

4. 证书验证的完整路径

证书验证就像查身份证真伪，需要三步走：

4.1 证书格式转换

从抓包数据导出证书：

bash复制echo "308202..." | xxd -r -p > server_cert.der
openssl x509 -inform der -in server_cert.der -out server_cert.pem

4.2 公钥提取技巧

使用OpenSSL提取ECDSA公钥：

bash复制openssl x509 -in server_cert.pem -noout -pubkey | openssl ec -pubin -text

输出中的pub:字段就是验签所需的公钥点坐标。

4.3 证书链验证

创建CA信任链：

bash复制openssl verify -CAfile root_ca.pem -untrusted intermediate.pem server_cert.pem

某次政务云测评中，发现服务端证书虽有效，但中间证书未正确部署，导致Android设备无法建立连接。

5. 验签操作的关键细节

验签就像核对笔迹，需要严格遵循算法规范。以ECDSA-SHA256为例：

5.1 OpenSSL验签命令

bash复制openssl dgst -sha256 -verify server_pubkey.pem -signature sig.bin sign_origin.bin

5.2 Python验签示例

python复制from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives import serialization

with open("server_pubkey.pem", "rb") as f:
    pub_key = serialization.load_pem_public_key(f.read())

pub_key.verify(
    signature=bytes.fromhex("3045..."),
    data=open("sign_origin.bin","rb").read(),
    signature_algorithm=ec.ECDSA(hashes.SHA256())
)

5.3 常见失败原因

• 随机数错位：某项目将client/server随机数顺序颠倒
• 编码格式问题：证书包含BOM头导致长度计算错误
• 签名算法不匹配：服务端配置为SHA384但客户端用SHA256验证

去年某次渗透测试中，我们发现攻击者通过篡改证书长度字段，绕过了某厂商的验签检查。正确的防御做法是严格校验长度字段与实际证书大小的一致性。

6. 测评报告的必备要素

完整的密评报告需要包含以下技术证据：

1. 原始抓包文件（含完整握手过程）
2. 签名原文生成过程的十六进制对照
3. 证书链验证结果截图
4. 验签命令及输出日志
5. 异常情况的处理记录

建议使用自动化脚本记录测评过程：

bash复制#!/bin/bash
tcpdump -w handshake.pcap &
openssl s_client -connect target:443 -showcerts > ssl.log
# 自动提取验签要素...

记得某次等保测评时，因未记录Wireshark版本信息，导致监管机构对结果存疑。现在我的检查清单里永远包含环境信息记录项。