v4.23.2 之后：尽量分散特征

[RPRX]

虽然有 #704，但我认为它过长，且其中的主要问题已得到解决，所以新开了一个issue

v4.23.2 之后的关键是：最终目标到底是“与大多数golang程序完全一样”，还是“尽可能像主流浏览器”？但可以肯定的是不能取中间值，否则又成了v2ray强特征

而如果做到“与大多数golang程序完全一样”，新版本被普遍使用时，可能相对于其它golang程序，v2ray的出境流量是最多的，到时golang的默认设置就成了特征，其它程序也会被波及

因此我建议分为两步实现：

1.参考 v2ray/v2ray-core#2522 实现“与大多数golang程序完全一样”，并把它作为默认设置

2.可以选择“尽可能像主流浏览器”，并内置多套方案，v2ray启动时随机选择一种。同时每次v2ray更新时，都要顺带更新内置的“浏览器方案”，越多越好。

毕竟如果只有一种“浏览器方案”，时间长了也会成为v2ray特征，所以思路是尽量分散特征

[p4gefau1t]

同意。我有一个想法，权当抛砖引玉：可以基于tlsfingerprint，以及社区自行抓包收集的方式，建立类似于geosite的TLS指纹数据库，并定期更新。客户端可以从该数据库中随机选取一个使用。

[RPRX]

同意。我有一个想法，权当抛砖引玉：可以基于tlsfingerprint，以及社区自行抓包收集的方式，建立类似于geosite的TLS指纹数据库，并定期更新。客户端可以从该数据库中随机选取一个使用。

赞同，我也这样想过 @kslr @vcptr @nicholascw @DuckSoft @Qv2ray-dev @darhwa

[nicholascw]

相比再提供一个 db 放 Cipher Suites 集合，我更倾向于支持 v2ray/v2ray-core#2517 的做法，然后默认值仍然是 Golang 默认值。

[darhwa]

其实不需要维护什么数据库，每次TLS握手时随机生成一个CipherSuites列表就行。这个列表的长度、顺序都可以随机。只要随机生成的这个列表里包含TLS 1.3那三个，就不影响实际握手过程。

[RPRX]

相比再提供一个 db 放 Cipher Suites 集合，我更倾向于支持 v2ray/v2ray-core#2517 的做法，然后默认值仍然是 Golang 默认值

相对于那个方案，我认为提供“套件集合预设”是有必要的，毕竟大多数用户没相关知识
而且除此之外“db”里还要有与特征相关的其它设置，并不只是加密套件

[darhwa]

然后extension的顺序也都可以改，但是这个麻烦点，还没详细看代码不知道uTLS目前支不支持。

[nicholascw]

大多数用户没相关知识

知道自己在干啥的都可以自己写配置 不知道自己干啥的都去找脚本包办了 没必要塞一堆进 core 啊

[RPRX]

其实不需要维护什么数据库，每次TLS握手时随机生成一个CipherSuites列表就行。这个列表的长度、顺序都可以随机。只要随机生成的这个列表里包含TLS 1.3那三个，就不影响实际握手过程。

也可取，但需要避免不合理的套件组合，或者说尽量合理

[RPRX]

大多数用户没相关知识

知道自己在干啥的都可以自己写配置 不知道自己干啥的都去找脚本包办了 没必要塞一堆进 core 啊

这是客户端，有GUI界面的对手动改配置不友好，用脚本主要是在服务器端

[darhwa]

静态数据库真的毫无必要，只要墙不用白名单，那么随机生成的就一样可用

[RPRX]

静态数据库真的毫无必要，只要墙不用白名单，那么随机生成的就一样可用

就“分散特征”来说，“随机化”可行且简单，至少比现在的都一样强很多

墙对这个用白名单不太现实，不然就误伤太多了

[RPRX]

目前没有太多选择，
一、Chrome 占了 20% 的 TLS 流量，其他诸如火狐等浏览器的流量几乎是零头。
二、随机化不是个好主意，你不可能在 Windows 上模拟 Safari 的 TLS 指纹吧（考虑操作系统网络栈被动指纹）。其次模拟小众 TLS 指纹某种程度上是方便了流量分类。

那么其他工具是怎么做的？cloak 模拟的是 Chrome 指纹，meek 的一种实现模拟的是 Firefox-ESR 指纹。

我是这么想的
1.墙应该不会关心也不知道我们用什么操作系统，况且无需非要模拟难度高的
2.随机化相当于把特征最大程度分散，即使随机到了小众指纹也足够隐藏自身，且每次启动都不一样
3.如果不采用“随机化”，要做到“分散特征”，只能建立合理的“浏览器数据库”，毕竟不能都用同一种

[rickyzhang82]

@rpx.

I don't think GFW will block V2Ray with Chrome signature if 20% of TLS traffic is from Chrome. This is a huge traffic percentage.

• Randomization itself can be a feature. I'm not sure how it could evade the classifiers.
• Randomize from a set of known signature in a data set is not quite practical. Because DB needs to be maintained and distributed.

Since Boring SSL may not change frequently as far as I know (I may be wrong), it is easier to mimic Chrome by using utls.

But first we need to understand the TLS traffic distribution in mainland China, before we move on the technical side.

[rickyzhang82]

Here is a proxy TLS statistics in China, assuming the web traffic is generated by web browser.

https://gs.statcounter.com/browser-market-share/all/china

[RPRX]

@rickyzhang82
首先，@错人了。。。
1.我也不认为墙会屏蔽表现得像chrome的v2ray，这是个可行的方案，只是我们需要“更多更多浏览器”，否则时间久了也会成为特征，所以在此方案下需要某种形式的db（毕竟浏览器每个版本指纹都不同
2.若墙要基于tls握手指纹进行流量分类，则它需要浏览器指纹白名单（而这是很难界定的），而且这种方案会误伤太多正常流量，因为随机到的指纹产生的流量可能只占相似指纹正常流量的百分之几
3.随机的主要是加密套件，而加密套件是有限的，其它选项也是有限的，所以随机化的方案同样可行

[rickyzhang82]

@RPRX

Sorry for my mistake.

The randomization can be the order of the ciphers (permutations) in TLS or be the select list of the ciphers (combinations) in TLS. If the known web browser doesn't behave randomly in terms of permutation and combination, V2Ray traffic may stand out from legitimate web traffice.

这是个可行的方案，只是我们需要“更多更多浏览器”，否则时间久了也会成为特征

Can you elaborate your reasoning from above? I don't get your points. Thanks.

The current fix in the commit is a suboptimal workaround. It can blend in V2Ray traffic as Golang 1.1x web client app depending on Golang compiler. Given the low popularity of Golang as a client, it is not a good choice.

[darhwa]

Randomization itself can be a feature

If the time window is big enough (say, we generate a randomized fingerprint per process, not per handshake), it's hard to tell we are randomizing. Yet it's still easy to tell the fingerprint is rare.

[rickyzhang82]

@darhwa On the contrary, every pseudo random number drew from a mathematical distribution can be identified given a large sample size. The law of large number dictates this.

[RPRX]

@rickyzhang82
并不是在每次请求时随机（那样特征当然很明显），而是在每次v2ray启动时随机。随机也不是完全随意，比如就像我前面提到的“需要避免不合理的套件组合，或者说尽量合理”。

浏览器的特征并不是一成不变的，拿chrome来说，82和72肯定不同，如果正常浏览网页都用82而v2ray还停留在72并有很大的出境流量，那就是强特征了。从另一个方面来说，go完全伪装成chrome可能比较困难，而有固定差异的情况下还有大量出境流量，也是很容易被识别出来的。

最后，我不认为开发时非要“二选一”，我认为这些方案可以逐一开发（甚至还可以更多），由用户自主选择。每种方案都有优缺点，同时方案越多就越能“分散特征”。（先睡觉，晚安

[darhwa]

@rickyzhang82 Only if they keep records for each client (or on the contrary, for each server) for some long time. Is that possible? I'm not sure.

[RPRX]

说一下为什么要“分散特征”：因为v2ray是公开发布的。如果特征固定，很容易被分析、针对。
而在合理随机化的情况下，v2ray tls的实际指纹则是到处散布的，难以被预先分析。
针对性机器学习？训练之后全国90%的出境tls握手看着都像v2ray。要的就是这种效果。

[phlinhng]

@RPRX 同意。我想 TLS 指纹的问题不在罕见而在于 "固定"，只要指纹足够分散与合理就足以形成混淆。

[Loyalsoldier]

私以为，将自身流量淹没在大海中是最好的归宿，并且，你的流量得每次都从同一条河汇入，要么一直像 Chrome 流量，要么一直像 Golang，要么一直像 Firefox。否则你一天从黄河而来，一天从长江而来，对于同一个家庭 IP 地址而言，过于蹊跷，也是一种特征。

目前而言，比较新版本的 Chrome 是这其中最大的大海。

[ActiveIce]

说的挺有道理的，那看来随机指纹也不是很好的解决方法，使用chrome网络层是最好的了。

[RPRX]

私以为，将自身流量淹没在大海中是最好的归宿，并且，你的流量得每次都从同一条河汇入，要么一直像 Chrome 流量，要么一直像 Golang，要么一直像 Firefox。否则你一天从黄河而来，一天从长江而来，对于同一个家庭 IP 地址而言，过于蹊跷，也是一种特征。

目前而言，比较新版本的 Chrome 是这其中最大的大海。

这种情况确实也需要考虑
如果紧跟新浏览器的，还是建个额外的数据库，和工具本身分开更新比较好

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days