Xtls vision reject vless-tcp-tls+Mux

[yuhan6665]

CC @RPRX

[RPRX]

感谢 PR，测试可行吗？建议不动回落，把取 firstBytes 移到函数里，因为它们的含义不一样。另外需要判断一下长度，防止 panic。

[H1JK]

Off-topic, but:

Xray-core/proxy/vless/inbound/inbound.go

Line 518 in f571aa7

". Note the pure tls proxy has certain tls in tls characters. Append \",none\" in flow to suppress").AtWarning()

Is characters a typo of characteristics?

[yuhan6665]

@RPRX 已经把 buffer 打出来看了 一切如你所料 :)
并且测试了客户端使用普通 MUX 和 XUDP
@H1JK 感谢反馈 我还在学习英语之中 我感觉这两个词意思差不多？

[RPRX]

目前这个函数只给 Vision 用，TCP TLS 的首包一定是 header+payload（尤其是 UDP 一定有 payload），所以可以默认返回 true，防止有先发 header 再发 payload 的实现（我记得 clash 是这样，长度特征超级明显，不知道现在改了没），刚好会绕过这个限制。

[RPRX]

（当然，要改为先判断 RequestCommandMux）

[RPRX]

Mux 时首包一定是 VLESS header + Mux header + 可能的 Mux payload（UDP 一定有），不过有 Mux header 就够我们判断了。

[H1JK]

我记得 clash 是这样，长度特征超级明显，不知道现在改了没

It hasn't changed yet. Trojan, Shadowsocks and something else are still writing request independently into the underlaying conn in Clash/Clash.Meta.

[RPRX]

根据代码，目前客户端填的 alpn 是没有应用到 uTLS 指纹的，你觉得是否应该应用？（除了 WSS） @yuhan6665

[RPRX]

我记得 clash 是这样，长度特征超级明显，不知道现在改了没

It hasn't changed yet. Trojan, Shadowsocks and something else are still writing request independently into the underlaying conn in Clash/Clash.Meta.

或许你可以给 Clash.Meta 实现首包粘连：

1. XUDP 早已是 VLESS 的一部分，Clash.Meta 的 VLESS 实现应当像 Xray-core 一样默认走 XUDP
2. 这个 PR 之后，XTLS Vision 的服务端会拒绝未实现首包粘连的 XUDP
3. XTLS Vision 的客户端如果没有实现首包粘连，将会是一个非常明显的特征，可能导致端口被封

[RPRX]

@yuhan6665 说起来，如果客户端没先发数据，得在 VLESS header 后粘个空的 padding，又要麻烦你了

[H1JK]

@RPRX Maybe padding also has some weaknesses. Shadowsocks 2022 edition adds a random length padding with up to 900 bytes. It eliminates the connection characteristic in request, but makes it to be a UNSTABLE protocol.

The "unstable" I mean is that when you repeatedly connect to the same TCP service (same IP and port), the length of the first packet varies significantly. And after that, client and server start a conversation, which means this connection is not only doing a upload or download operation. This might be a characteristic, since an application level protocol with random request length (and has even up to hundreds of bytes of randomly distributed variance) is not common and nearly imposible to be used so widely on mobile phones, laptops and other home devices. The use of TLS will not hide this because it is not too hard for censor to check out your first application data record.

I've heard that Shadowsocks 2022 is even easier to get blocked than Shadowsock AEAD (2017), that's my guess as to why this happens.

So, for that, the implementation of Seed may be a good solution. Limit the length jitter to a small range should be better than generate a full random length padding.

[yuhan6665]

根据代码，目前客户端填的 alpn 是没有应用到 uTLS 指纹的，你觉得是否应该应用？（除了 WSS） @yuhan6665

是应用 uTLS 时 alpn 失效是吧？#1274
我也不知道该怎么办 所以打了个问号 本来我觉得这属于特殊使用场景可以不管 但结合待解决的问题1 横竖都需要对 randomized 指纹下手 变化 randomized 指纹应该OK 其它浏览器指纹最好不要动我觉得

[RPRX]

根据代码，目前客户端填的 alpn 是没有应用到 uTLS 指纹的，你觉得是否应该应用？（除了 WSS） @yuhan6665

是应用 uTLS 时 alpn 失效是吧？#1274 我也不知道该怎么办 所以打了个问号 本来我觉得这属于特殊使用场景可以不管 但结合待解决的问题1 横竖都需要对 randomized 指纹下手 变化 randomized 指纹应该OK 其它浏览器指纹最好不要动我觉得

对！我也觉得除了 randomized，其它指纹不能应用 alpn 设置，否则总会有人去选，连累服务端，一开始就不应该给他这个机会

[yuhan6665]

@yuhan6665 说起来，如果客户端没先发数据，得在 VLESS header 后粘个空的 padding，又要麻烦你了

如果没理解错 你是说给 clash 那边加 vision 的时候要注意 padding 问题：
目前 padding 实现是遇到 TLS client handshake 即 第一个payload 开始加（考虑协议和流控解耦和 流控只看协议 payload）但是 clash 的问题是没有把协议首包和第一个 payload 粘起来
还有一个问题是目前 padding 起始是 UUID 如果协议头再加一个有点奇怪。。
（也许可以让他们独立把这个粘包问题修了？）

[Larvan2]

注意到radar中 CN Top Browsers & User Agents的情况主要为Chrome,Safari 和 UC，据此判断应该可以缩小随机指纹选择空间，并根据数据按概率选择随机指纹。

[RPRX]

如果没理解错

理解错了，我指的是如果应用发起了 TCP 连接但没发数据，VLESS 会只发自己的协议头，长度特征比较明显，不如粘个 padding

[RPRX]

注意到radar中 CN Top Browsers & User Agents的情况主要为Chrome,Safari 和 UC，据此判断应该可以缩小随机指纹选择空间，并根据数据按概率选择随机指纹。

random 有过这个想法，维护可能有点麻烦，PR is welcomed，虽然我们在聊的是 randomized（随机生成的指纹）

[yuhan6665]

如果没理解错

理解错了，我指的是如果应用发起了 TCP 连接但没发数据，VLESS 会只发自己的协议头，长度特征比较明显，不如粘个 padding

那我懂了，是指某些 ssh 客户端和一些其它特殊协议服务端先发包的情况吧，确实是个可能的问题 这个不会block reality出世吧

[RPRX]

@RPRX Maybe padding also has some weaknesses. Shadowsocks 2022 edition adds a random length padding with up to 900 bytes. It eliminates the connection characteristic in request, but makes it to be a UNSTABLE protocol.

The "unstable" I mean is that when you repeatedly connect to the same TCP service (same IP and port), the length of the first packet varies significantly. And after that, client and server starts a conversation, which means this connection is not only doing a upload or download operation. This might to be a characteristic, since an application level protocol with random request length (and has even up to hundreds of bytes of randomly distributed variance) is not common and nearly imposible to be used so widely on mobile phones, laptops and other home devices. The use of TLS will not hide this because it is not too hard for censor to check out your first application data record.

I've heard that Shadowsocks 2022 is even easier to get blocked than Shadowsock AEAD (2017), that's my guess as to why this happens.

So, for that, the implementation of Seed may be a good solution. Limit the length jitter to a small range should be better than generate a full random length padding.

@H1JK 你说的是有道理的，除了，你先假设了我说的 padding 指的是大范围随机 padding，并不是，显然我也知道那是送人头
我的意思是，在客户端不先发数据时，把 Vision 为 Client Hello 准备的 padding 粘到 header 后，毕竟其它结构服务端也识别不了
这样的话，至少在这种情况下，它的首包长度是符合 Vision 的历史数据的，相对稳定。如果要改，它们也会一起改。

不过你说的引申出了一个问题，那就是：是否在任何情况下，都应该 padding，以保证至少一去一回两个首包的长度相对稳定？
我觉得这个是值得实践的，前提是启用 seed 参数，以确保每个人都能配置不同的长度特征。

TLS data record 长度是明文，我觉得见仁见智，因为审查者肯定重点依赖它，但它是可以被我们控制、利用的。之前我提过一句 match:xyz，控制流量特征匹配某一可能的“白名单”规律，指的就是比如 把浏览网站的真实流量特征记录下来，代理流量直接 reshape 成它的形状（通过 split 或 padding），主要就是控制 TLS data record 的长度，专门送给审查者看。

[RPRX]

这个不会block reality出世吧

不会，你看我已经开始生成 *.pb.go 了，就是在往 Xray-core 加 REALITY，再写完文章后它就会和大家见面了

但是会 block 下一个版本发布