TLS指纹问题

[katayaburi]

有一篇gist谈到了目前主流支持TLS的科学上网协议的TLS指纹情况，想问一下这个问题对V2Ray来说需要解决吗？

[ailinwang]

我把Cisco的论文看了一遍，上面写的主要特征来源于SSL的Hello包，我想需要对握手包做特定的变换，可以增加一个虚拟层，使用一些混淆算法实现。这个issue提到的特征似乎是针对的http/2协议的V2RAY，不知道其他的几个通信协议怎样，圣诞假期搭环境看看特征。

[INX-2001]

好多大佬

[katayaburi]

这里是这篇gist原作者在Trojan项目中提交的Issue。

[katayaburi]

以及作者的项目以供参考，不是为了推荐，而是因为在项目的说明中作者阐述了他自己的观点（FAQ部分）。

[kotori2]

#1660

[k79e]

想要完美的可以去用naiveproxy
其他库的tls流量理论不算在异常范围内.

[kotori2]

@k79e 看了下 那个项目貌似也很硬核，直接把Chromium丢到源码里，不过原理上猜测只是H2套壳socks5？
不过个人感觉这也不是一个很好的操作，首先chrome版本变了要把chromium的源码同步过来，用户也需要更新客户端，作者维护这么多版本号也存在弃坑的可能。
所以我还是觉得uTLS的实现比较好，握手过程只要把浏览器的行为抓一下包就行了，并且用户可以通过配置随便切换浏览器和版本号。另外因为是客户端层面上的实现，也不需要防止主动探测出幺蛾子。

[kotori2]

@k79e 另外不要因为一个TLS指纹就把他说成“远远超过”，个人觉得V2Ray的鲁棒性和功能性远高于naiveproxy。

[k79e]

@kotori2 他基本上就是个改进的trojan 说远远超过没什么问题.
当年trojan伪装上面有些问题 nativeproxy如果做的没问题. 别提什么超过不超过 说秒杀都不是问题.
况且网络那部分不是老修改 又不是用户界面 没必要总是更新.
网络这方面如果老变动的话 那做统计的也没法统计了 这个版本这样那个版本那样.

[klzgrad]

@kotori2 不硬核，不是把Chromium丢到源码里，是在Chromium的基础上加了一串补丁，用Chromium自己的build system编译出来。

原理上，现在文档推荐的是socks5转h2，不叫套壳，不是socks5套在h2里面。也可以变成socks5转quic或者任何Chromium支持的代理协议，但经我评测现在推荐的是转h2。

维护上的工作主要在于Chromium版本更新以后rebase的时候偶尔有merge conflict，实际工作量大概每两个月Chrome出新版的时候我会花一个晚上把新版本build出来。

“作者维护这么多版本号”是一个误判，只有master是维护的，因为按照指纹一致的原则，用户必须用最新版本才能跟Chrome最新的版本一致。切换浏览器也是没有必要的，选用人数最多的那个效果就已经最好了。

uTLS不用它的原因是它只仿真了ClientHello，其他更复杂的静态信息，和TLS栈里状态转移的动态信息都仿真不出来。举个最简单的例子，uTLS在ClientHello里面加了brotli压缩的参数，但是证书并没有实际用brotli压缩。这一下就检测出来了。Chrome 69就开始用brotli压缩证书了 https://www.chromestatus.com/feature/5696925844111360。看过这篇 https://ieeexplore.ieee.org/abstract/document/6547102/ 的从业人员都知道著名的“鹦鹉已死”的结论。

说谁秒杀谁，同行相互贬低，不是很有意义。但实际情况是trojan项目刚成立的时候我就参与了，经过调研之后发现很多设计上的问题（上面已经讨论了），但是trojan的主程又没空，所以后来才分出来自己做的naiveproxy。但是实际情况又证明那些设计上的问题都是理论问题，实际中trojan不是用得好好的嘛？

跟v2ray比的话，v2ray肯定是现在市面上功能性最完善的一个。但是鲁棒性要怎么定义，如果是抗检测的鲁棒性，naiveproxy采取的抗检测措施肯定要比v2ray多，具体什么措施其实自己调研看论文就知道了。不过这些都是理论问题，最初我没用v2ray的原因是觉得自行发明密码学和嵌套加密（vmess over TLS）太不雅观，不知道这是不是最近有用户汇报v2ray在性能上都比naiveproxy慢的原因。

总之v2ray有它的特点，TLS指纹现在还停留在理论问题。但不一定哪天就成为现实问题，所以我的建议，还是认真调研一下。

[kotori2]

@kotori2 不硬核，不是把Chromium丢到源码里，是在Chromium的基础上加了一串补丁，用Chromium自己的build system编译出来。

原理上，现在文档推荐的是socks5转h2，不叫套壳，不是socks5套在h2里面。也可以变成socks5转quic或者任何Chromium支持的代理协议，但经我评测现在推荐的是转h2。

维护上的工作主要在于Chromium版本更新以后rebase的时候偶尔有merge conflict，实际工作量大概每两个月Chrome出新版的时候我会花一个晚上把新版本build出来。

“作者维护这么多版本号”是一个误判，只有master是维护的，因为按照指纹一致的原则，用户必须用最新版本才能跟Chrome最新的版本一致。切换浏览器也是没有必要的，选用人数最多的那个效果就已经最好了。

uTLS不用它的原因是它只仿真了ClientHello，其他更复杂的静态信息，和TLS栈里状态转移的动态信息都仿真不出来。举个最简单的例子，uTLS在ClientHello里面加了brotli压缩的参数，但是证书并没有实际用brotli压缩。这一下就检测出来了。Chrome 69就开始用brotli压缩证书了 https://www.chromestatus.com/feature/5696925844111360。看过这篇 https://ieeexplore.ieee.org/abstract/document/6547102/ 的从业人员都知道著名的“鹦鹉已死”的结论。

说谁秒杀谁，同行相互贬低，不是很有意义。但实际情况是trojan项目刚成立的时候我就参与了，经过调研之后发现很多设计上的问题（上面已经讨论了），但是trojan的主程又没空，所以后来才分出来自己做的naiveproxy。但是实际情况又证明那些设计上的问题都是理论问题，实际中trojan不是用得好好的嘛？

跟v2ray比的话，v2ray肯定是现在市面上功能性最完善的一个。但是鲁棒性要怎么定义，如果是抗检测的鲁棒性，naiveproxy采取的抗检测措施肯定要比v2ray多，具体什么措施其实自己调研看论文就知道了。不过这些都是理论问题，最初我没用v2ray的原因是觉得自行发明密码学和嵌套加密（vmess over TLS）太不雅观，不知道这是不是最近有用户汇报v2ray在性能上都比naiveproxy慢的原因。

总之v2ray有它的特点，TLS指纹现在还停留在理论问题。但不一定哪天就成为现实问题，所以我的建议，还是认真调研一下。

其实仔细想想这个点子还是不错的，最开始我是觉得Chromium这么大的项目编译出来不管是体积还是内存占用都很可怕，但是看了下实际上还不错。
另外自行发明协议也只是VMess层面上的内容，如果去掉VMess的话，ws+tls原理就跟naive proxy一致了。我觉得套个vmess主要是为了鉴权？以及，他也没自己造轮子，只是调了官方的tls库，实现了粒度更精细的控制而已。
性能上的话，Go的特性导致他的runtime编译出来挺大的，占内存也多。虽然比隔壁python版ss好一点，但是性能肯定是比c++差。
我觉得吧，先把tls指纹的问题放在一边，不管是你使用代理聊天，还是看视频，一天长时间连着tls，已经是一个很明显的特征了。即使是ws，用的人也不多。（虽然我也没更好的想法就是了

[klzgrad]

可以给你介绍一下为什么这么小。程序组织上，本质就是把Chromium的base库和网络库抽取出来，再加上我的main函数，然后在Chromium的build system里加一个target，编出来一个可执行程序，这样完成的。

你说的长连接的问题我考虑过。长连接本身要深度检测很麻烦，现在主流的流量分类方法都是抽取连接开头几个长度做分类，连接后面做分类要记录大量数据，在资源上就比较吃力，所以长连接被深度检测的可行性较小（但不是不可能）。其次也不能否认长连接有合理应用，比如如果我是在线会议，或者页游，都可能产生合法的长连接。第三，naiveproxy实际使用中也不是一个连接用一天，如果隧道内的链接都没了，隧道本身的连接过一会也自动关了。这几个点本身还是无法把连接长度降到典型网页访问的模式，但也不是裸奔的状态。

Edit: 相反的，如果是1:1的短连接，这才是真正明显的特征，为什么。因为浏览器有规定，访问每个网站的并发连接数是不高的。如果两个站点之间并发数高于一般浏览器的并发数，就可以显著判断不是浏览器流量。

[emc2314]

其实没必要那么硬核, 可以参考 tor 的 meek-plugin, 里面有两个后端, 一个是 utls, 一个是 webextension, 它通过自己写的一个 firefox extension 来把流量通过 firefox 发出去, 代码比较轻量, 而且也是 go 语言实现.

[emc2314]

之前提过一个 feature request, 当时发现 utls 已经存在于 v2ray 里, 于是关闭了. 一年过去了发现没什么变化, 我就自己 fork 了一下, 把 tls 直接替换成了 utls, 默认模拟 Chrome 72 的 fingerprint. 改动很少, 可供测试.

但是遇到几个问题, 比如 QUIC 使用的是 qtls, 所以没有改动. 其次, websocket 的 tls 是直接将 wss:// 格式的 URL 传入第三方库, 为了使 websocket 使用 utls 我只能 fork 这个 websocket 库再修改其代码.

最严重的问题在于, 大多浏览器都支持 http/2, 如果服务器也支持的话会自动升级到 http/2. 所以, 当 websocket 使用模拟的 chrome fingerprint 时握手时, ALPN 会协商出 http/2. 但是目前 go 的几个 websocket 库都不支持 bootstrap from http/2: gorilla/websocket#417, coder/websocket#4.

为了解决这个问题, 我在我 fork 的 websocket 代码中加入判断, 如果传入的 URL 以 "/h2" 结尾, 则使用ALPN 中没有 http/2 的 safari 的 fingerprint, 这样就不会协商出 http/2 了.