很好奇识别的原理

[FyZhu97]

trafficstars

如题，大佬能简单讲一下吗

[RPRX]

TLS 握手消息长度特征比较固定，而 Trojan 在设计上只是简单套了一层 TLS 加密，没有掩盖内层流量特征，所以可以被轻易识别。 可以看一下 https://github.com/XTLS/Trojan-killer/issues/4 中的讨论和 https://github.com/XTLS/Trojan-killer/blob/main/main.go ，代码很简单。

---

其实很多东西三年前我介绍 VLESS 的理念时就说过了，查看 https://github.com/v2ray/v2ray-core/issues/2636 Flow 那段，只是 GFW 不封就没人在意。 就像当初我说 https://github.com/v2ray/v2ray-core/issues/2523#issuecomment-636548331 ，还有人跟我 argue，现在比照着我当初的发言再看看现状：

1. GFW 精准封锁全随机数裸协议，~~被迫再造 SSR 但又会被针对~~，此外，以前的威胁是协议黑名单，现在有协议甚至 SNI 白名单
2. 加密设计上，光我就给它们找出了一堆漏洞，我还常说它们没有前向安全，~~日后有内鬼爆出来 GFW 确实有解密就搞笑了~~
3. TLS 类（包括 H3 的 QUIC）百花齐放，依附于广泛使用的 TLS 确实会使 GFW 对于封锁有所顾忌，提高了封锁的成本和代价
4. 但是你用 Trojan 大概率隔天封端口，因为并非简单套个 TLS 就万事大吉，必须要有 Flow、Seed 机制，以对抗流量分析

现状过于符合三年前我被一些人认为是“过于激进”的一系列观点，他们没想到真的会这么刺激，看来我拿到的是一张预言家的牌。

我都怀疑自己消失那段时间是去升级 GFW 了，你看时间都完全对得上。你品，你细品。那我就不装了，我摊牌了：~~我开玩笑的。~~

[Fangliding]

就是看握手的时候传输数据的大小 upcount 650 ~ 750 downcound 170 ~ 180 or 3000 ~ 7500

[FyZhu97]

感谢回复。 代码之前就看了，是很好理解的。疑惑的点在于为什么传输数据是这个特定数值，就可以判断为TLS in TLS呢？ 大佬懒得解释的话给点参考资料也行，嘿嘿

[RPRX]

可以看一下 https://github.com/XTLS/Trojan-killer/issues/4 中的讨论

[wiketool]

可以看一下 #4 中的讨论

看了下代码和 #4 的讨论，请问暴露了内部TLS的流量特征是否可以这么理解，通过流量分析的手段，发现在当前TLS的数据中包裹着另外一层TLS；然后这种行为是反常的，就可以检测出来。我现在还有一个疑问，Trojan-killer其实针对的是TLS-over-TLS？通过判断TLS-over-TLS来认定是trojan协议

[mytbk]

我很早就知道TLS-over-TLS是可以检测的了，但是就近几年我的使用情况来看，我用stunnel做的socks5-over-TLS代理几乎没有被封过。

[xzlosats111]

话说这么久了这个问题还没有被解决吗，最近发现不同域名被针对的力度不一样，不论vless tojan，那几个经典的免费域名，正常访问可以访问，一旦我连了TiT，就会被阻断个几分钟，其他域名不会这样 另外在设计上我不能理解，为什么外层握手时需要包含内层TLS握手的内容，而不是外层建立连接后再用普通连接建立内层握手，内层tls握手包隐藏在外层普通tls流中，我想不到这么做的问题，为什么实现不了呢，有没有大佬解释一下