服务端 TLS 指纹

[arm64v8a]

TL;DR

v2ray TLS 服务器 存在独特的指纹。

解决方案：请考虑应用前置（套个 Nginx HAProxy Caddy 什么的）

抱歉，有点像“弄个大新闻”，实际影响多大还需项目组人士评估。

起因

最近网络上流传一份 IP 列表，很多是 v2ray TLS，也有部分误报。

TLS 协议实现复杂，参数多， 考虑到 v2ray 之前在 客户端 方面出现了独特的指纹，服务器出现这种问题也不奇怪。但是 issue 搜了一圈，居然没人提到。

过去的讨论： v2ray/discussion#704 v2ray/v2ray-core#2098 v2ray/v2ray-core#2542

复现

网络资产搜索引擎常用 jarm 表示一个 TLS 服务的指纹。

影响 jarm 的因素有 证书类型（如RSA/ECDSA）、 Go 版本、代码中的 TLS 设置等。

jarm 需要连接服务器进行测试，应该属于主动探测。

简单测试得到一些结果

golang http.ListenAndServeTLS (go 1.18)

(ECDSA)
40d1db40d0000001dc43d1db1db43de
0a012c76cf078b8d06f4620c2286f5e

(RSA)
3fd21b20d00000021c43d21b21b43de
0a012c76cf078b8d06f4620c2286f5e 

v2ray 4.44.0-5.0.6 (go 1.17-1.18)

(ECDSA)
40d1db40d0000001dc43d1db1db43d2
f70423af611c314ea6b67982756f7de

(RSA)
3fd21b20d00000021c43d21b21b43d2
f70423af611c314ea6b67982756f7de

v2ray 4.41 (go 1.16)

1dd1eb40d00040d1dc42d1eb1db41d7
8dd8236626f2926d4bf2ca9ae325b54

caddy (go 1.18)

40d40d40d00000000043d40d40d43da
936ab0256fab25eca082941d14e3ece

如何判断这个指纹 “普遍都是v2ray” 呢？

前往某资产搜索网站搜索 jarm

这是 40d40d40d00000000043d40d40d43da936ab0256fab25eca082941d14e3ece caddy 的分布

这是 40d1db40d0000001dc43d1db1db43d2f70423af611c314ea6b67982756f7de v2ray 的分布

从机房分布大概可以看出这是什么人在用。

https://beta.shodan.io/search/facet?query=http&facet=ssl.jarm

也可以知道这个指纹是比较小众的。

题外话

如果我是 hostloc 该帖楼主，我可以下载很多一键脚本，包括带nginx前置的，然后收集指纹拿去搜索，看上去分布比较像的都可以拉清单。或许这个 IP 列表就是这样来的。

复现的过程中还搜到了 gost 和 x-ui 的指纹（小声）

[arm64v8a]

update:

该帖楼主似乎已把扫描方法贴出。

抱歉，本帖要求阅读权限高于 50 才能浏览

检测 Xray \ v2ray tls 直连包，欢迎拿包测试

[bash99]

如果caddy指纹也有问题，那么套一个caddy怎么解决呢？

[klzgrad]

我印象中v2ray不是有很多nginx反代websocket的推荐配置吗？是不是已经解决了问题

[arm64v8a]

@klzgrad

已经有现成的应用前置方案。不过按照上面的方法统计，直接用 ws tls / trojan tls 的人还有很多。

在 v2ray 的 issue 区内，我没看到有人关注过「服务器有指纹」这个问题，于是发帖讨论一下。

[bash99]

已经有现成的应用前置方案。不过按照上面的方法统计，直接用 ws tls / trojan tls 的人还有很多。

直接用v2ray解tls的好处是支持回落，否则用nginx卸载ssl，后端传输层基本上就只能走ws/grpc协议了，而grpc协议在网络差的情况下偶发卡死现象较多。

就原理理解sni模式实际暴露的指纹应该也是后端的v2ray等。

[arm64v8a]

@bash99

这个帖子说明的原理：什么程序处理 TLS 就会显示什么程序的特征。

[bash99]

看了下某个网站的结果
caddy指纹大概是 255,278 条匹配结果 （ 59,576 条独立IP）
v2ray指纹大概是 46,366 条匹配结果 （ 23,697 条独立IP）

不考虑独立ip，caddy大概还算安全；v2ray不知道是否混有其它go语言服务器端的结果。

单纯从服务端指纹看，极端安全的还是 nginx 后套ws/grpc（但是最好别用一键脚本的ssl配置，自己用nginx缺省配置或者CF公开的配置 此处感谢 klzgrad）；
其次可能是 haproxy + naiveproxy 模式，
下面这个组合不知道能否走通： haproxy（卸载ssl） -> grpc 或者haproxy（卸载ssl）-> caddy -> grpc/ws

[klzgrad]

我不理解“回落”这个功能的意义在哪里，如果是伪装，按照上面的描述，回落也起不到伪装的作用

[bash99]

我不理解“回落”这个功能的意义在哪里，如果是伪装，按照上面的描述，回落也起不到伪装的作用

应该就是方便单域名下支持多个协议（或者更简单的单个软件支持多个协议）

[Yebolin]

这个应该普遍性不强吧。
我的是这个 JARM: 29d3fd00029d29d00042d43d0000008aec5bb03750a1d7eddfa29fb2d1deea
我感觉应该相同也反映不出什么，有人相同不？

[bash99]

这个应该普遍性不强吧。 我的是这个 JARM: 29d3fd00029d29d00042d43d0000008aec5bb03750a1d7eddfa29fb2d1deea 我感觉应该相同也反映不出什么，有人相同不？
拿这个jarm一搜，170,132 条匹配结果 （ 83,767 条独立IP）

你这个是nginx解ssl的？如果是ws/grpc应该没啥漏洞，如果是sni分流，应该拿分流的域名测试。

[arm64v8a]

我的结论：

1. jarm 不能定位 v2ray 的特有设置，不能确定 internet/tls/config.go 里面的哪些东西容易被扫。
2. 不同于针对 ss 的主动探测，这个问题可能未被（墙相关人员）实际利用，只见到有人无聊扫特征。
3. 已经有足够多的方案应对此类问题。如 caddy / nginx 反代。