如何评价 Xray 的主要开发者发布的检测 TLS in TLS(trojan) 的小工具？
a632079 2023-05-13 21:14:13 +08:00 17383 次点击这是一个创建于 883 天前的主题，其中的信息可能已经有所发展或是发生改变。
Xray 的主要开发者 RPRX 发布了一个简单检测 TLS in TLS 的工具，它可以精准地检测出 Trojan 代理。
以下为仓库 README：
这个 POC 是为了 狠 狠 打 脸 某些认为 TLS in TLS检测不存在或成本很高的人。
该程序在
127.0.0.1:12345接收 TLS 流量，并用 非 常 廉 价 的方式检测出其中的 Trojan 代理。
- 设置浏览器的 HTTP 代理至
127.0.0.1:12345，观察该程序的输出。- 设置 Trojan 链式 HTTP 代理至
127.0.0.1:12345，观察该程序的输出。我们的测试结果如下：
- 对于浏览器的 HTTPS 流量，几乎没有阳性结果。
- 对于 Trojan 的 TLS in TLS 流量，Trojan 字样直接刷屏。
这与我们多次收到的 Trojan 被封、XTLS Vision 存活的反馈相符（它们均可选 Golang 指纹）。
值得一提的是，根据我们的观察，目前 REALITY 的“白名单域名”会被豁免于这样的检测。
 | 1 yaoxuming 2023-05-13 21:24:32 +08:00 via Android  2 说的好，但我选择 ipv6 ，ss 都没人管 |
 | 2 liulongquan 2023-05-13 21:29:23 +08:00 |
 | 3 yaott2020 2023-05-13 21:41:12 +08:00 via Android xray tg 群组还有更加劲爆的内鬼消息 |
| 4 yaoxuming 2023-05-13 21:44:13 +08:00 via Android @liulongquan 电信可以用 cf 的优选 ipv6 ，除了晚高峰都有保障。教育网走香港 hkix 拉港台新澳飞快，欧美不太行 |
 | 6 mohumohu 2023-05-13 21:57:28 +08:00 无所谓了，现在还有多少直连的机场？ |
 | 7 BigShot404 2023-05-13 22:13:45 +08:00 这是拆台还是反拆台？ |
 | 8 cnbatch 2023-05-13 22:42:05 +08:00 既然这样，我选择用 UDP |
 | 9 deorth 2023-05-13 22:45:09 +08:00 via Android 5 rprx 这样子又不是第一天了。我建议加大力度，加速双方技术竞争 |
 | 10 MeMoDiv 2023-05-13 22:45:49 +08:00 这个脚本主要检测上传和下载的数据包大小特征来判断目标主机是否可能被感染恶意软件。 具体的特征条件是: 上传数据包大小在 650 到 750 字节之间; 同时,下载数据包大小符合以下两个条件之一: 1. 在 170 到 180 字节之间; 2. 在 3000 到 7500 字节之间; |
 | 11 wdlth 2023-05-13 22:59:55 +08:00 应该是通过 TLS 1.3 的 Change Cipher Spec 进行检测吧 |
 | 12 K8dcnPEZ6V8b8Z6 2023-05-13 23:28:09 +08:00 @yaott2020 人在群组，错过了什么？无内鬼来点消息 |
| 13 yaott2020 2023-05-13 23:51:02 +08:00 via Android 1 @K8dcnPEZ6V8b8Z6 风向旗评论区有，自己看 |
 | 14 leewi9coder 搞事情搞事情 |
 | 15 benedict00 2023-05-14 00:06:44 +08:00 估计还有人还在 simple-obfs 呢吧 |
| 17 leewi9coder 2023-05-14 00:10:04 +08:00 请直接告诉我哪个协议和配置最安全 |
 | 18 MZSAN 2023-05-14 01:22:56 +08:00 via Android 这个程序写得很简单，只是简单检测一下大小 套个 grpc 可暂时缓解，但特征依旧存在。 实际上，Trojan tls in tls 的 client hello 特征非常明显。而理论上所有 TLS in TLS 都可以监测，并且由于 TLS IN TLS 的特征几乎只会在代理中出现，误杀有但较少，所以不排除特殊时期 GFW 会采用这种相对激进的监测手法。 |
| 19 MZSAN 2023-05-14 02:16:16 +08:00 via Android 2 另外也别觉得 Reallity 就能解决问题，目前已经可直接通过 DNS 来检查访问 IP 是否属于所声称的域名。偷域名的方案 reallity/shadowtls/restls 一概通杀。。 https://github.com/3andne/restls/issues/8 |
 | 20 C47CH 2023-05-14 02:20:33 +08:00 2 GFW 去年就完成升级了，好像还有一篇文章专门测试 GFW 的。 |
 | 22 nnbbaa 2023-05-14 05:40:37 +08:00 via Android 白名单域名有哪些？ |
 | 23 764594334 2023-05-14 06:00:56 +08:00 分享个我用的,openai/流媒体解锁，5 元起，不限速不限制流量，现在很多机场跑满会限制你 aHR0cHM6Ly9zdXBwb3J0Lmh1Y2xvdWQubWUv |
| 24 764594334 2023-05-14 06:03:09 +08:00 发错了想发隔壁，当没看见 |
 | 25 naminokoe 2023-05-14 06:36:50 +08:00 via iPhone 4 最终解决只能靠润的 |
 | 26 Cormic 2023-05-14 08:12:22 +08:00 via iPhone 土法建模 |
 | 27 makelove 2023-05-14 08:57:33 +08:00 我没用这些高科技，只用 ss+obfs ，几年来没中招过，不知道是流量少每月才几百 G 还是别的原因 |
 | 28 lovelylain 2023-05-14 08:57:52 +08:00 via Android @MZSAN #18 套 nginx 能避免包大小问题吗？ |
 | 29 div class="sep3"> MFWT 2023-05-14 10:26:25 +08:00 IPv6+原版 SS 路过 即使是晚高峰时期，中国移动，依然可以正常连接到美国机器 v6 还是一片净海，SS 毛问题没有，用不着 TLS |
 | 32 XIU2 2023-05-14 10:50:03 +08:00 4 @gearfox @Danswerme 连接服务器走的是 IPv4 还是 IPv6 ，不影响 服务器访问目标网站走的是 IPv4 还是 IPv6 。 除非这个服务器只有 IPv6 地址，这种情况下，服务器才只能通过 IPv6 访问目标网站，不过这种情况也可以套 WARP+ 解决。 目前来说，各系统的这方面网络策略都相同，当设备有 IPv4+IPv6 时，会同时解析域名的 A 记录和 AAAA 记录，如果有 AAAA 记录，则会通过 IPv6 访问该网站（即优先 IPv6 ），反之则走 IPv4 。 而这个优先级也可以通过修改系统文件来控制是 IPv6 优先，还是 IPv4 优先。 Linux 可以修改文件： /etc/gai.conf 找到下面这行并移除行首的 # 注释符，或者把这行插入文件底部也行： precedence ::ffff:0:0/96 100 这时 Ping 谷歌域名就是 IPv4 地址了。 |
 | 34 d1g1tal0cean 2023-05-14 12:28:29 +08:00 via Android 1 他这个就是老鼠有四条腿一个尾巴，所以有四条腿一个尾巴的都是老鼠 |
 | 37 Remember 2023-05-14 13:39:07 +08:00 1 这个人性格有大问题，轴的很，从 debian 官方源的协议事件就能看出来。 v2ray 作者弃坑之后，他本可以接手整个项目的，但他怼完用户怼团队，最后自己 fork 了一个。 |
 | 39 SekiBetu 2023-05-14 15:37:48 +08:00 2 @Remember 对的，所有开源用户必须使用 MIT 协议，用其他协议的人性格都有问题，为什么不大方开源代码呢，小心我们 Debian 用户的铁拳砸到这些非 MIT 协议支持者的头上！ |
| 40 SekiBetu 2023-05-14 15:39:33 +08:00 @Remember https://lists.debian.org/debian-vote/2022/10/msg00000.html 早就该骂骂这种人了了，上次不骂，结果 Debian 也开始搞非开源软件进来了，太恶心了，不用 MIT 协议的都去_啊 |
 | 41 JingKeWu 2023-05-14 16:25:07 +08:00 难怪前几天服务器 ip 被封了 |
 | 43 awinds 2023-05-14 18:33:00 +08:00 就目前这么多协议来说，哪个最安全？ |
 | 44 BFDZ 2023-05-14 18:51:34 +08:00 tls 从去年大规模封锁开始就表现出不稳定了，肯定是被识别了 |
 | 45 Danlianbiao 2023-05-14 19:33:18 +08:00 @XIU2 v6 的透明代理不好弄啊 |
 | 46 zushi000 2023-05-14 20:15:26 +08:00 很多不懂技术的过分吹捧某种技术,虽然我也不懂技术.但是这个事情以前发生过.以前 ss 被爆出遭特征检测时,很多人也不承认,过分神话某个技术.没想到现在又发生这种事情了 |
 | 47 azure2023us559 2023-05-14 21:36:40 +08:00 @yaoxuming v6 wireguard 一直很稳 |
| 48 azure2023us559 2023-05-14 21:41:06 +08:00 ss (no encryption ) over tls 路过， |
 | 52 datocp 2023-05-15 06:45:12 +08:00 via Android 吃瓜群众路过。上次哪位朋友也告诉我 stunnel 也有像某某的特征。我还以为 tls 是普通人的特征，大家都有的特征就不叫特征？ 问题是为什么这些旁门左道软件容易被封？用户基数大？ stunnel 不也一样的特征？ stunnel 在连接前验证客户端身份，我觉得还是有用的。不验证有时候可能是中间人？发现连接会被插包出现错误。 tls1.2-1.3 满大街都是。。。 |
 | 53 0o0O0o0O0o 2023-05-15 08:16:50 +08:00 via iPhone 2 @datocp #52 > 我还以为 tls 是普通人的特征 譬如 tls fingerprint > 问题是为什么这些旁门左道软件容易被封？用户基数大？ stunnel 不也一样的特征？ 单单三个主要的 V2Ray-core 项目加起来 80k star ，还有各类周边生态，还有别的协议，issue pr 不计其数，你定义为旁门左道的标准是什么？ 我不想与你争论 stunnel 和它们谁更好用，但请你意识到一点：GFW 是个黑盒，对抗它的人没有人真的知道它具体是怎么运作的，中国很大，网络环境很复杂，网络需求也不同，所以“个体差异”也很夸张，有些人用远古协议裸奔一样说没被墙，但前沿探索是要照顾“短板”的，也就是更容易被墙的人的。目前的它们的种种奇思妙想是灵丹妙药吗？不是，但面对不断升级的 GFW ，停止对抗的探索你觉得是正确的态度吗？ （ V2Ray：A unified platform for anti-censorship.） > stunnel 在连接前验证客户端身份 这些年，TLS 乃至于 QUIC 都被你定义的旁门左道圈子玩出花来了，你说的都是很基础的操作。 |
 | 54 Masoud2023 2023-05-15 11:32:06 +08:00 RPRX 前阵子不是说失踪了么，vless 都不维护了？ |
 | 55 Xiaosteven 2023-05-15 11:37:16 +08:00 @0o0O0o0O0o 我一直觉得 GFW 上千企业很难没有内鬼的，而且也不排除挟“盗”自重的可能。只需要在敏感时期调高审核力度就可以对上面交差了 |
 | 56 ungrown 2023-05-15 13:31:21 +08:00 2 @cy18 #51 哪来的无特征这种说法，境外节点，无名小站，莫名其妙的主页，多到吓人的加密流量，这 4 大特征去不掉，却因掩盖了包长度之类的小特征而沾沾自喜，脑子有坑。 |
 | 57 LnTrx 2023-05-15 17:19:54 +08:00 1 @ungrown 其实这几个还算正常 境外节点：国外 APP 很正常 无名小站：很多知名服务背后提供服务的域名也很怪 莫名其妙的主页：提供服务的域名没有主页都很正常 多到吓人的加密流量：毕竟 https 等已经很普及了 如果真按这个标准作为特征，误杀率想必居高不下 |
 | 58 FrankAdler 2023-05-15 18:15:15 +08:00 希望类似的工具再多点，被识别就淘汰很正常，我流量一个月才 50G ，都被阻断 443 了，目标暂时用机场代替了。 PS: 推广 stunnel 的那个真是勤快啊，要不是有人回复了他，我都不知道他也回这个帖子了 |
| 60 SekiBetu 2023-05-15 20:36:44 +08:00 @Remember 你可以不用别人的代码，但是你不能逼着作者去修改开源协议，我觉得这是作为一个人最基本的道德，不过，你例外，你的思维就是和某 G 一样，"奉献自己才是对的，你都把代码公开了，为什么不修改协议为 MIT 呢？你是不是有私心？这样是不行的，我们 Debian 用户没有方便快捷的 v2ray 包可以用了，不能一键 apt install 了，你要被批判，要大字报批判你！这是对开源的不尊重！只有 MIT 协议才是我们 Debian 用户最纯正的信仰！" |
| 61 SekiBetu 2023-05-15 20:44:02 +08:00 @Remember handbrake 源代码里 include 了 fdk-aac ，fdk-aac 的许可和 gpl 是不兼容的，但是 handbrake 也没有直接移除 fdk-aac 相关代码，只是不在二进制分发内包含 fdk-aac 这就是国外社区的和谐，到了简体字社区，一群人拿着自由软件过来冲作者，强制要求改成 MIT 协议与上游 v2ray 保持一致，以满足他们在 Debian 做包的目的 |
| 62 SekiBetu 2023-05-15 21:17:32 +08:00 @Remember 一个伟人的语录，仅供参考，这个观点应该与你的想法一致，不然怎么会对我的回复反应如此激烈 > 我认为如果你在使用开源软件（例如 Linux ，Go 语言），那对开源社区就是有愧的，所以做一点开源软件就想当于还债> 了。有些人还一点，有的人还多了，大部人不还。但是以这个角度看就不是自己免费工作让别人利用了。因为开源软> 件的开发者肯定是期待你以开源软件回报的。 |
 | 63 Kinnice 2023-05-16 10:16:06 +08:00 @FrankAdler #58 这个老哥在几乎每一个涉及到科学上网的都要说一下 stunnel 多好用，自己用着多稳定。我使用 stunnel 跑了一波大流量测试后，还是被封端口。也许是幸存者偏差，真稳定还得是 IPLC 。 |
| 65 LnTrx 2023-05-18 15:54:09 +08:00 @doruison 误杀是指被误以为是梯而干掉。单纯数据不在境内流量又大被封是不是应有之义，外界不知道，能知道的只是有许多现存健在的案例。 |
 | 66 huahsiung 2023-05-19 22:21:52 +08:00 @0o0O0o0O0o 现在我也很纳闷，软件流量大容易被封？？，完全是被神话的软件猜测,之前 ss 被封这样说，v2 被封也这样说，tls 被封也这样说。，实际上知道的人少的软件就不容易被封？？（比如有一个天天吹自己不会被封的 ssr over tls ，还有 2021 年前的 naiveproxy ） 每次出现问题，一群小白都说是流量大被封，从 2015 到现在，从未改变 |
 | 67 philippiela 2023-05-21 10:23:08 +08:00 流量就是最大的特征，有哪个境外 ip 会长时间大流量的连着一个境内 ip ？ |
 | 68 luvjoey1996 2023-06-02 00:49:33 +08:00 没理解代理链的说法，我在本地构建了一个环境 trojan-client -> tunnel ( http proxy client -> trojan-killer) -> trojan-server ，没发现有检测出来 trojan 流量，有没有懂的大佬出来解惑一下。 |
 | 70 qsnow6 2023-11-15 10:37:19 +08:00 大流量确实会被 Ban ，自己试下不开代理，从境外网站下一些几百 M 的文件试试，连接经常被中断。 |
 | 71 lijiangang886 2023-11-22 23:33:57 +08:00 1 和主题无关，从其人种种事迹看，这个作者看起来确实不像个情绪稳定的成年人 同时这和他对爬梯事业做出的诸多贡献是两码事，不可混为一谈 |
 | 73 ailiyaqin2003 348 天前 @yaoxuming 电新用 cf 的 ipv4 延迟太高了，不如移动 |
| 74 ailiyaqin2003 327 天前 @yaott2020 内鬼？不是有人喷 rprx 让 xray 停止更新吗 |
Select Language