Add fingerprint xray_random

[yuhan6665]

xray_random means to pick a random uTLS fingerprint at the core startup
This way, the fingerprint is stable for a user for some days. While there is no identifiable signature for the whole xray community
CC @RPRX

[RPRX]

我觉得 random 如果是对 uTLS 支持的几乎所有指纹进行随机选择的话，仅 random 而言，长期会呈现出比例接近均匀分布，尤其是在过时的指纹上，这是不真实的。更好的方式是我们根据现今互联网上的指纹占比统计，预置一个权重，每个版本更新，加上不止一个设备同时使用（同时存在多个不同指纹且时间范围不完全重合），且不一定都选 random，这样相对真实。

[Fangliding]

@RPRX 然而墙看到的是 一个人拿着Chrome Firefox甚至Safari在访问一个网站

[RPRX]

@RPRX 然而墙看到的是 一个人拿着Chrome Firefox甚至Safari在访问一个网站

I can't get your point.

[yuhan6665]

更好的方式是我们根据现今互联网上的指纹占比统计，预置一个权重，每个版本更新

这感觉维护的工作量有点大 一个简单的办法把特别老的指纹去掉算了
另外 @RPRX 有其他开发者们请求 PR Vision 的功能 我在思考单独在 XTLS community 底下放一个库 然后 xray-core 依赖新库 请问你觉得怎么样？

[RPRX]

这感觉维护的工作量有点大 一个简单的办法把特别老的指纹去掉算了

也不是不可以

另外 @RPRX 有其他开发者们请求 PR Vision 的功能 我在思考单独在 XTLS community 底下放一个库 然后 xray-core 依赖新库 请问你觉得怎么样？

没问题，新库可以叫 XTLS / Vision，我们下个版本后再依赖新库，防止不小心把下个版本改炸了
如果能顺便把对内层 TLS 的分析再单独抽出来成一个库就更好了，它会很有用

[RPRX]

这个选项叫 random 吧，你合并后我再加些选项供 GUI 直接选，除此之外，下个版本还需要有：

1. randomized 选项行为改为指纹锁定，先写成全局的，写起来比较简单（WSS 特殊处理）
2. XTLS Vision 服务端默认拒绝非 XUDP 的 Mux 请求
3. XTLS Vision 两端均检测自身 TLS 版本，非 TLSv1.3 时断连

加油，我的 Reality 鸽多久放出来就看你了
最终我没有 fork uTLS 库，因为感觉 uTLS 库没有及时更新代码，所以这里的代码还是只能写成现在这样

[cross-hello]

Have a good time, though writing code during Spring Festival may not be a preferred choice.

[yuhan6665]

@RPRX 研究了一下问题 2 确实在 Vision 服务端复现了存在的问题：客户端如果开了 VLESS - TCP - TLS + MUX 的情况是可以连接的 我看了一下最简单的方法是检查客户端的 flow 设置 只允许 Vision 客户端连接 但是注意到只有 TCP command 时客户端才会发 flow

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

Line 152 in 3fb67f0

requestAddons.Flow = ""

这块的逻辑有点奇怪 为什么不能统一都发 flow？感觉以后应该会有用 之前踩这个坑的时候就想请教您来着 :)

关于问题 3 我猜是因为 Reality 的特殊需要？看了一下应该可以加个检查 ConnectionState

[FranzKafkaYu]

@yuhan6665 @RPRX 新年快乐，代码可以暂时放放了。

[RPRX]

@yuhan6665 因为事实上目前除了 TCP command，flow 并不会影响 body，没有起到作用，预留到以后起到作用时再发会更有用。
Single XUDP 的端口是 666，可以用来与真正的 MUX 区分。

关于问题 3 我猜是因为 Reality 的特殊需要？

不是，是 XTLS Vision 的特殊需要，防止有人给 TLS 配置了 "maxVersion": "1.2"。
Reality 会确保自身的版本是 TLSv1.3，没有这个问题。

[yuhan6665]

@yuhan6665 因为事实上目前除了 TCP command，flow 并不会影响 body，没有起到作用，预留到以后起到作用时再发会更有用。 Single XUDP 的端口是 666，可以用来与真正的 MUX 区分。

关于问题 3 我猜是因为 Reality 的特殊需要？

不是，是 XTLS Vision 的特殊需要，防止有人给 TLS 配置了 "maxVersion": "1.2"。 Reality 会确保自身的版本是 TLSv1.3，没有这个问题。

问题3 应该可以了：#1554
我本来也认为只有 maxVersion 这一个设置 想着属于瞎写配置的用户问题 结果测试的时候真发现问题了 原来 uTLS 的 randomized 指纹会有一定概率协商出 TLS 1.2！结合你说的问题1 确实应该把目前的 random 的行为改为锁定 这样即使摇出了 TLS1.2 结果连不上 用户可以重新摇（需要在文档里面注明这个坑）

我看了一下 XUDP 的实现 目前我的理解是 666 只是客户端的一个标记并没有发到服务端

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

Lines 69 to 73 in 3fb67f0

	if request.Command != protocol.RequestCommandMux {
	if err := addrParser.WriteAddressPort(&buffer, request.Address, request.Port); err != nil {
	return newError("failed to write request address and port").Base(err)
	}
	}

所以服务端似乎是无法区分 XUDP 和普通的 MUX 包的？

[RPRX]

问题3 应该可以了：#1554 我本来也认为只有 maxVersion 这一个设置 想着属于瞎写配置的用户问题 结果测试的时候真发现问题了 原来 uTLS 的 randomized 指纹会有一定概率协商出 TLS 1.2！结合你说的问题1 确实应该把目前的 random 的行为改为锁定 这样即使摇出了 TLS1.2 结果连不上 用户可以重新摇（需要在文档里面注明这个坑）

是的，我写 Reality 时也发现了 randomized 有时会协商成 TLSv1.2，我觉得干脆在摇出来后检测一下吧，Extension: supported_versions 为空或其中 TLSv1.3 不在开头（除了 Reserved）时就重来，毕竟也能少一个 RTT。
文档需要说明过时的指纹、hellorandomized、hellorandomizedalpn、hellorandomizednoalpn 可能是 TLSv1.2。

我看了一下 XUDP 的实现 目前我的理解是 666 只是客户端的一个标记并没有发到服务端

我看了一下代码，看起来 VLESS 和 VMess 的确都只会发 MUX 的指令，不会发地址和端口，看来我写 XUDP 时可能忘了它没发
但我还留了一手，至少在 *ray 的实现中，MUX 中子连接 ID 是从 1 开始的，而 Single XUDP 的子连接 ID 恒为 0
顺便判断一下 MUX 内第一个包是否为 UDP，我觉得就足够了