关于 RPRX 指出另外两核 chrome指纹有问题---初分析

技术交流
1

之前提了要了解一下指纹问题，简单分析下，仅收集资料不涉及代码、验证部分，有时间补全

正文

来源1 : https://t.me/zaihuapd/42287

sing-box uTLS Chrome 指纹缺少后量子密钥交换，与真实 Chrome 产生可区分特征

sing-box 的 uTLS “chrome” 指纹未包含 X25519MLKEM768 混合后量子密钥交换曲线，而 Chrome 131+ 已将其作为默认密钥交换组。两者在 supported groups 和 ClientHello 结构上存在差异，使得 sing-box 的 TLS 指纹可被高级检测区分。sing-box 曾提供 chrome_pq 等后量子专用指纹，但在 1.10.0 版本移除并回退到普通 chrome，原因是该指纹与 Reality 协议不兼容（触发 nil ecdhe_key 错误）。

值得注意的是，sing-box 的 curve_preferences 配置项默认列表确实包含 X25519MLKEM768，但这属于标准 TLS 引擎的逻辑，uTLS fingerprint 模块走的是独立的 ClientHello 模仿机制，二者互不影响。sing-box 官方文档已明确不推荐 uTLS，指出其反复被发现指纹漏洞、无法完美模仿 BoringSSL 等浏览器栈行为，建议改用 NaiveProxy 获取更强的抗指纹能力。

(初始)来源 2: https://web.archive.org/web/20260407155945/https://github.com/SagerNet/sing-box/issues/2084

uTLS 的 “chrome_pq” 指纹无法与 Reality 配合使用（ecdhe_key 为 nil）

如果我在客户端将 uTLS 指纹（fingerprint）设置为 “chrome_pq”，并搭配 VLESS+XTLS-Reality 服务端使用（已在 Xray 和 Sing-box 上测试，无论 flow 设置为 “xtls-rprx-vision” 还是留空，结果都一样），则无法连接，并报错 “nil ecdhe_key”。
将指纹设置为 “chrome”、“firefox” 或 “edge” 均能正常工作，唯独 “chrome_pq” 无法使用。
此外，使用 VLESS+XTLS-Vision 或 VLESS+TLS 搭配 “chrome_pq” 指纹也能正常工作；只有在将 “chrome_pq” 指纹与 Reality 结合使用时才会出现问题。

sing-box 后续反应: https://sing-box.sagernet.org/zh/configuration/shared/tls/#utls

utls

仅客户端

不推荐

uTLS 已被研究人员多次发现其指纹可被识别的漏洞。

uTLS 是一个试图通过复制 ClientHello 结构来模仿浏览器 TLS 指纹的 Go 库。 然而，浏览器使用完全不同的 TLS 实现（Chrome 使用 BoringSSL，Firefox 使用 NSS）， 其实现行为无法通过简单复制握手格式来复现，其行为细节必然存在差异，使得检测成为可能。 此外，此库缺乏积极维护，且代码质量较差，不建议用于反审查场景。

如需 TLS 指纹抵抗，请改用 NaiveProxy。

mihomo 后续反应:

https://wiki.metacubex.one/config/proxies/tls/#reality-opts

Warning

由于 xray-core 刻意的不兼容行为，我们不会考虑 xray v26.7.11+ 版本的兼容性，如果不能使用请更换服务端（如 mihomo 原生 listener，sing-box 或旧版 xray-core），或用其他协议替代

而且有支持 X25519-MLKEM768 密钥交换的参数 reality-opts.support-x25519mlkem768

2

个人点评:
gfw.report 曾经提到过一段 [流量混淆策略]

Tschantz等人将混淆翻墙流量的方法分为两类：隐写(steganography)和多态(polymorphism) [57, § V]。隐写代理的目标是使翻墙流量看起来像应该被允许的流量；多态性的目标是使翻墙流量看起来不像应该被禁止的流量。

实现隐写术的两种最常见的方法是模仿(mimicking)和隧道传输(tunneling)。Houmansadr等人 [39]得出结论，模仿类协议有着根本性的缺陷，并指出将原始流量通过被允许的协议进行隧道传输是一种更抗封锁的方法。Frolov和Wustrow二人 [35]证明，即使使用隧道传输，翻墙软件的设计者仍然需要额外的努力让翻墙协议的指纹与流行的实现方式的指纹保持完全一致，以避免受到基于协议指纹的封锁。例如，在2012年，中国和埃塞俄比亚部署了深度包检测系统，通过Tor使用的不常见的密码套件来检测Tor流量 [44,67,55]。审查设备供应商之前已经根据meek [29]发出的TLS指纹和SNI值来识别并封锁它了 [28]。

为了避免这种复杂性，许多流行的翻墙软件选择了多态的设计。实现多态性的一个常见方法是，从连接中的第一个数据包开始，就对其有效载荷进行完全加密。由于没有任何明文或固定的包头结构指纹，审查者没办法简单地使用正则表达式或通过寻找流量中的特定模式来识别代理流量。这种设计在2009年首次被引入Obfuscated OpenSSH [16]。此后，Obfsproxy [24]、Shadowsocks [22]、Outline [42]、VMess [23]、ScrambleSuit [68]、Obfs4 [7]都采用了这种设计。Geph4 [58]、Lantern [20]、Psiphon3 [21]和Conjure [33]也部分采用这种设计。

完全加密的流量经常被称为“看起来什么都不像”的流量，又或者被误解为“没有特征”；然而，更准确的描述应该是"看起来像随机数据"。事实上，这种流量确实有一个使其与其他流量不同的重要特点：完全加密的流量与随机流量是无法区分的。由于没有可识别的头，整个连接中的流量都是均匀且高熵的，甚至在第一个数据包中就已经如此。相比之下，即使像TLS这样的加密协议也还有相对低熵的握手包，用以传达支持的版本和扩展。