uTLS的padding会不会可能成为一个特征？

[stark131]

兄弟们，发现一个地方性的异常，把自己的意见分享出来给大家看下。

最近我发现经常被省墙block，比如这个省的xray client连server是OK的，另一个省就时不时阻断tls和server IP。

基本配置：
vless+tls_tcp, xtls-rprx-vision
xray client ver 1.7.5
client hello里的padding option并不是在末尾的，而常规的chrome/edge/safari/python等浏览器/tls库发送的tls client hello，padding option全都是在末尾。
在配置下，第一个连接建立后不到3秒钟，省墙立马block掉server IP（icmp ssh tcp均大量超时，偶尔会通），持续时间为几分钟。这期间，另一个省连server还是稳定OK的。

我尝试把服务器地址配置直接改成IP，xray client发出来的client hello就不包含padding，当然也不包含SNI（因为我没有指定server name，这个问题和SNI没有关系，我已确认过），现在已经稳定将近1天没有被block了。
不知这个padding option在包里的位置是否会被省墙判定为是一个xray的特征？
不知是否有其他人在南方某省遇到同样问题？

我抓了chrome/python/xray xtls vision/xray xtls without vision对同一个server发起tls的client hello报文，如有需要可以脱敏上传。

[chika0801]

如果能上传更好，谢谢你的热心

[stark131]

下面是xray ver v1.7.5 vless+xtls+vision向某个server发出的tls client hello的hex
请注意，第一个字节开始就是应用层数据，不包含IP层和传输层，SNI我也删掉了。

另外，还有一个值得注意的地方，我发现这个tls client hello的第一个cipher suite是CHACHA POLY而不是AES128/AES256，而server端总是会选择第一个可用的cipher。xray client是如何给这些cipher排序的？
请注意，我并没有在配置中指定任何cipher suite。

0000   16 03 01 02 00 01 00 01 fc 03 03 a6 8a 43 8e 84
0010   8a 04 6a 2e 20 e2 41 3d b8 f5 e8 9e 8c 87 52 30
0020   1f df a5 48 94 86 e3 ab 78 d2 af 20 41 5e e3 69
0030   c4 a6 ee dc bf ce 1f 55 8c 36 80 6e d8 d5 4f aa
0040   ea ea 71 ca 81 b3 97 f2 77 c1 a4 d5 00 26 13 03
0050   13 02 13 01 00 9d c0 2c c0 27 c0 2b 00 9c cc a9
0060   cc a8 c0 2f c0 0a 00 35 c0 14 00 2f 00 0a c0 12
0070   c0 13 c0 09 01 00 01 8d 00 0a 00 0a 00 08 00 1d
0080   00 17 00 18 00 19 00 12 00 00 00 17 00 00 00 2b
0090   00 09 08 03 04 03 03 03 02 03 01 00 00 00 19 00
00a0   17 00 00 14 这里是20字节长度的SNI，已删掉，请自己补全
	   00 10 00 0e 00 0c 02 68
00c0   32 08 68 74 74 70 2f 31 2e 31 00 15 00 d3 00 00
00d0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00e0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00f0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0100   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0110   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0120   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0130   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0140   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0150   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0160   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0170   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0180   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0190   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01a0   00 44 69 00 05 00 03 02 68 32 00 23 00 00 ff 01
01b0   00 01 00 00 0b 00 02 01 00 00 2d 00 02 01 01 00
01c0   0d 00 18 00 16 06 03 08 05 05 03 04 01 02 01 04
01d0   03 02 03 05 01 08 06 08 04 06 01 00 33 00 26 00
01e0   24 00 1d 00 20 ae d5 71 c6 36 35 ad 77 e8 d5 12
01f0   78 f9 e6 8b 54 89 c1 82 6c 31 8d 42 7e d7 4b 70
0200   f7 da c1 a4 36

[RPRX]

首先，你说的是 uTLS Client Hello 的 padding，而不是 XTLS Vision 的 padding，请分清它们不是同一个东西，标题我帮你改了。

[RPRX]

其次，报告问题是好事，但能不能不要拿 randomized 指纹来问“为什么它和chrome/edge/safari/python等不同”，我看不懂。

[stark131]

其次，报告问题是好事，但能不能不要拿 randomized 指纹来问“为什么它和chrome/edge/safari/python等不同”，我看不懂。

进一步测试后，我也意识到了这个问题。
首先，我一开始以为xray用的是自己的TLS、没有引用其他库，这是我的问题，感谢你的纠正。

但是，这是一个真实的事件，我从来没有说这是一个bug、需要修复，只是想共享出来看下是否有其他人遇到相似异常。
至于这个randomized选项，这是一个肉眼都能看出来的不同寻常之处，randomized都random得能让人一眼看出来不是常规浏览器或库发送的请求了，还有random的意义吗？

[RPRX]

f32921d

But we should avoid using it unless we have to, see refraction-networking/utls#157 (comment)

简单来说，当你所在的地区连常规浏览器的指纹都封锁时，可以试一下 randomized 指纹，否则不要用。

[xianren78]

你那个IP被省墙当成CDN管理了，我猜运营商是电信。

[moranno]

你那个IP被省墙当成CDN管理了，我猜运营商是电信。

我在这边也观察到和 @stark131 一样的现象：ihciah/shadow-tls#78

运营商也是电信。
所以最终原因还是IP被省墙当成CDN了？

[xianren78]

你那个IP被省墙当成CDN管理了，我猜运营商是电信。

我在这边也观察到和 @stark131 一样的现象：ihciah/shadow-tls#78

运营商也是电信。 所以最终原因还是IP被省墙当成CDN了？

我有一个韩国甲骨文也一样待遇了，北方电信

[ArcCal]

想扶墙就不要用中国电信

[stark131]

你那个IP被省墙当成CDN管理了，我猜运营商是电信。

我有俩运营商，异常出现时电信和联通都不通，根本说不通。。。 路由都完全不一样，怎么俩运营商还能一起被阻断的。

不过我把这个randomized指纹修改成常规的chrome/firefox之后起码目前是OK的（SNI随便填都OK），randomized fingerprint肉眼看起来都特别明显，暂时还是不用了。

[Fangliding]

@stark131 建议试一试前段时间很神奇的Safari(现在版本叫IOS)

[stark131]

你那个IP被省墙当成CDN管理了，我猜运营商是电信。

我在这边也观察到和 @stark131 一样的现象：ihciah/shadow-tls#78

运营商也是电信。 所以最终原因还是IP被省墙当成CDN了？

SNI不填应该问题不大，证书最好确保是有效且可信的吧。

你下面说的这个结论不一定完全对，域名解析是可以设置解析线路的，比如电信IP和联通IP去查询同一个域名，是可以得到不同的IP的。我认为墙目前不会做得这么麻烦。。
老域名 + 老证书 + 新域名sni + 跳过证书验证 = 阻断 （验证sni与dns记录值是否比对）
老域名 + 新证书 + 新域名sni + 跳过证书验证 = 不阻断（验证sni与dns记录值是否比对）

[stark131]

我在ver 1.7.2的release里也看到了这个，这个指纹为啥这么神奇？

[cross-hello]

From Chrome 110, each website connection will involve a random fingerprint.
net4people/bbs#220

[moranno]

你那个IP被省墙当成CDN管理了，我猜运营商是电信。

我有俩运营商，异常出现时电信和联通都不通，根本说不通。。。 路由都完全不一样，怎么俩运营商还能一起被阻断的。

不过我把这个randomized指纹修改成常规的chrome/firefox之后起码目前是OK的（SNI随便填都OK），randomized fingerprint肉眼看起来都特别明显，暂时还是不用了。

是否发生阻断和IP段深度相关，我测试了冷门IP（中东）不会引发阻断，而且美国IP引发阻断。