uTLS: Update ModernFingerprints map and OtherFingerprints map

[Davoyan]

No description provided.

[Fangliding]

也许我们应该在utls弄一个api而不是每次复制列表

[ghost]

也许我们应该在utls弄一个api而不是每次复制列表

there's no good way to implement that you will still have to dump fingerprints, just google user agent/CH fake wont work reliable

[ghost]

none of these are modern currently, google chrome moves users and usually 60-90% users remain on modern client hints/fingerprints (latest) within a week or two after release

these are extremely outdated
not a single modern anti bot solution wouldve allowed a user connect to a website if they had this as CH (not the state of xray, just a statement on how outdated these are)

[Fangliding]

你理解错了 chrome指纹不是每个版本都会更改（这涉及到TLS库的更新） 里面列出的基本是chrome CH产生差异的版本 133和目前最新的149 150没有区别
以及auto会自动指向最新的版本 现在只是没法手动填入chrome133而已 大多数人用还是正常用的

[ghost]

yeah i understand what you meant, but when i was checking it in wireshark fingerprints (not client hints) were different (i was checking with publicly available ones, from those curl libs, maybe that's why), but yeah, we'd still need ability to push the user to user the latest ClientHints as well

plus we cant really keep forcing mobile clients pretend to user fingerprints/ClientHints of a PC version

				HTTP User-Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36
				Sec-CH-UA	"Google Chrome";v="143", "Chromium";v="143", "Not A(Brand";v="24"
				Sec-CH-UA-Platform	"Linux"
				Sec-CH-UA-Mobile	?0
				Sec-CH-UA-Full-Version	"143.0.7499.169"
				Sec-CH-UA-Full-Version-List	"Google Chrome";v="143.0.7499.169", "Chromium";v="143.0.7499.169", "Not A(Brand";v="24.0.0.0"
				Sec-CH-UA-Platform-Version	""
				Sec-CH-UA-Arch	"x86"
				Sec-CH-UA-Bitness	"64"
				Sec-CH-UA-WoW64	?0
				Sec-CH-UA-Model	""
				Sec-CH-UA-Form-Factors	"Desktop"

we are also temporarily forced to change to firefox

[Fangliding]

这个PR是关于 TLS client hello 指纹 你写的这些是 HTTP Header 不要搞混了

[ghost]

> yeah i understand what you meant

Client hints also require attention however

[ghost]

what does unsafe do?

[Fangliding]

yeah i understand what you meant

Client hints also require attention however

这和这个PR无关

[ghost]

Do a research on ja3/ja4/ja3n vs CH detections, can't be bothered repeating myself, you're just going to create another caveat for xray detection, but once again, it is related to this PR's context, just because you've mentioned that we need a normal API for that

https://www.cdnetworks.com/blog/cloud-security/tls-fingerprinting-bot-mitigation/

[Fangliding]

我那条消息的意思只是在utls内建一个这样的map避免每次更新指纹都需要在xray内部同步更新一个map而已（不是没有这样的先例）

这整套伪装的具体逻辑在 https://github.com/XTLS/Xray-core/blob/main/common/utils/browser.go 你可以通过在transport中设置 user-agent 来指定你需要的预设或者禁用

[Davoyan]

Comment for Russian community:
This PR is not about what you’re probably thinking. The current stable XRAY release, v26.3.27, already uses HelloChrome_133 (the latest Chrome fingerprint in the utls library) by default when you set fingerprint: "chrome" in the config. This PR only allows you to use fingerprint: "HelloChrome_133" as a strict option for testing purposes, similar to fingerprint: "HelloChrome_131".

[RPRX]

话说 @iambabyninja 给我发邮件提到了前几天俄罗斯针对完全标准的 Chrome 133 指纹限制了 TCP 连接数，一些精华片段：

The Mihomo situation is particularly interesting.

Their uTLS and Chrome fingerprint implementation is actually fine. However, after adding post-quantum support, they decided to use an older Chrome fingerprint (Chrome 120). As a result, everything works while post-quantum is disabled, but once post-quantum is enabled, drops start happening again.

I also compared the JA4 fingerprint against a real Chrome instance on Windows, and Mihomo matches it almost 1:1.

sing-box, on the other hand, does not match the real Chrome JA4 at all, which may be exactly why it is not triggering the blocks right now. Instead, it takes the new fingerprint and manually strips references to X25519MLKEM768, without considering that such a modified ClientHello may end up having extremely distinctive characteristics

很抱歉迟迟没有发 stable release，但是即将发的新版的 release 与 v26.3.27 的 Chrome 指纹没有区别 —— 都是最新版 Chrome，而从你描述的情况来看，俄罗斯 GFW 应该是针对最新版 Chrome 指纹限制了连接数，因为在真正的 Chrome 中 TCP 最大连接数为 6，那么 1:1 的 XTLS flow 已经不适用了，在此推荐你们设置 XHTTP 的 maxConnections 为 6，或者使用 Browser Dialer 会更真实，只是后者暂时不能结合 REALITY

Chrome 浏览器是自动更新的，我认为无论是 Mihomo 的选择不带 X25519MLKEM768 的 Chrome 120 指纹还是 sing-box 的在最新版 Chrome 指纹中移除 X25519MLKEM768 都会造成强特征，现在只是因为它们在俄罗斯的用户相对较少所以尚未被 GFW 针对而已，一旦被关注到那么这类强特征将是不可解决的，除非换成最新版且未修改的 Chrome 指纹

For now, we are using either mux or simply setting the HelloChrome_120 fingerprint, similar to Mihomo without post-quantum, so this is not critical for us.

We also did some more experiments here.

One interesting thing about mux.cool is that it can spawn connections almost endlessly. There does not seem to be a maximum connection limit setting like in smux or xmux (or at least we are not aware of one).

As a result, some guys are using 4 gRPC outbounds behind a roundRobin balancer — and it actually works 😀
However, the memory usage ended up being even higher than with XHTTP.

In the end, some people stayed with regular TCP RAW using compressed mux:
3 outbounds for TCP and 1 outbound for UDP.
TCP traffic was separately passed through a balancer across the three TCP outbounds, while UDP used its own dedicated outbound.

This way, no more than 4 connections are established.

我们多次收到（疑似）来自俄罗斯的 AmneziaWG 支持请求，这样的协议在俄罗斯是否工作？

#6200

目前 Finalmask 已有非常多的功能，你们那边是否有测试过不同组合在俄罗斯的可用性？

AWG only works because its market share is still below 1%.
The fact that they added junk in packet did not make it anything exceptional.

The same effect as AWG can be achieved using FinalMask.

Right now, we are experimenting a lot with FinalMask.
We use VLESS encryption or Shadowsocks with various masking techniques. For example, a couple of hours ago we received this ********* setup in the attachment (*********) — it works exceptionally well.

I have not checked the quality of the configuration itself, so there may be mistakes in it, but it works even on very “dirty” IP addresses.

I just ask you not to share this config publicly, since it is not mine.

Sing-box 和 Mihomo 这 Chrome 指纹问题。。。怎么感觉狼人越来越多了

[RPRX]

@Davoyan 至于这个 PR，顺便更新下 Modern 等列表吧，比如移除过时指纹，你们可以讨论一下

[Davoyan]

I think we should make the random selection use weights based on statistics, instead of giving each fingerprint equal chances. Or maybe we should create a separate option called like "random_statistic_based" or something that uses these fingerprints with weight.

(Not final weights presented, it's just for example)

"chrome":        &utls.HelloChrome_Auto,  # 66%
"firefox":       &utls.HelloFirefox_Auto, # 5%
"safari":        &utls.HelloSafari_Auto,  # 10%
"ios":           &utls.HelloIOS_Auto,     # 15%
"edge":          &utls.HelloEdge_Auto,    # 4%

[ZeN220]

i think it would be a good idea to code-generate fingerprints from utls during Go compilation. It would also be possible to define policies so that some of the fingerprints end up in the modernPool (minimum versions for each of the browsers or something else). this will eliminate the need for constant commits with utls changes

[RPRX]

I think we should make the random selection use weights based on statistics, instead of giving each fingerprint equal chances. Or maybe we should create a separate option called like "random_statistic_based" or something that uses these fingerprints with weight.

random 还是倾向于尽量随机，不然应该叫 real-world distribution

[RPRX]

@Davoyan 修一下 fmt

[RPRX]

另外想到了一个好玩的东西，代理时 TLS 只改 SNI、服务端改回来，且分散到不同的服务器，但可能有 per-app tls ch fp 问题

[RPRX]

refraction-networking/utls#373 (comment) Chrome 148 没改指纹，不过 uTLS 也确实就没有发过 Type: pre_shared_key (41)

[Davoyan]

@RPRX As I mentioned in refraction-networking/utls#373 (comment), in real Chrome 148 on Windows, pre_shared_key only appears after the first handshake starting from the second connection and subsequent ones.

I tested this multiple times, and according to my results, TCP RAW VLESS Reality, when opening new connections, does not replicate this behavior. It’s always without pre_shared_key.

In uTLS, I found this implementation: https://github.com/refraction-networking/utls/blob/master/u_pre_shared_key.go

I’m not sure whether it is possible to correctly implement this behavior in VLESS TLS/Reality. Also, I don’t fully understand how it is used inside uTLS.

[RPRX]

@Davoyan 我记得我之前在 issue 中提过这个来着，正在找链接，虽然目前所有基于 uTLS 的应用貌似都没发这个

对于 TLS 实现它不难，不过对于 REALITY，不清楚把 REALITY 的 pre_shared_key 发给目标网站会触发什么行为，如果它还是能响应正常的 sever hello 什么的那还好，毕竟 CH 中还有 key_share，然后 REALITY 服务端 trim 掉一些东西就行，得研究下

话说我抓这网站 server hello 中的 pre_shared_key 咋是 Selected Identity: 0 呢，你那里有没有 selected 非 0 的样本

[RPRX]

找了很久没找到链接，应该是 2023/2024 年的时候在一个 issue 下面说了 uTLS 三点，2025 修 REALITY 时提过 Chrome 的行为