PoC: 协议探测风险

shadow-tls的设计已经过时，Telegram MTProto FakeTLS已经采用过这种设计，而且更为完善
服务端参考代码
但是依然被GFW封锁，此方法已经过时了，开发者早日弃坑吧

[H1JK]

If you don't know what you are doing, please close this issue.

If you don't know what you are doing, please close this issue.

MTProto FakeTLS在TLS ClientHello中使用secret进行hmac，将hash值填充在tls.random字段中，服务器可以在clienthello中进行判断，验证客户端有效性，但是依旧被识别，这种方式已经过时了

[ihciah]

If you don't know what you are doing, please close this issue.

MTProto FakeTLS在TLS ClientHello中使用secret进行hmac，将hash值填充在tls.random字段中，服务器可以在clienthello中进行判断，验证客户端有效性，但是依旧被识别，这种方式已经过时了

感谢反馈！

没太仔细看 mtproto 的实现，是在 client hello 里携带签名信息吗？
基于 client 主动签名的算法无法防止重放攻击，只有 challenge-response 形式的验证可以。

我的一些想法可以参考这里： https://www.ihcblog.com/a-better-tls-obfs-proxy/

If you don't know what you are doing, please close this issue.

MTProto FakeTLS在TLS ClientHello中使用secret进行hmac，将hash值填充在tls.random字段中，服务器可以在clienthello中进行判断，验证客户端有效性，但是依旧被识别，这种方式已经过时了

感谢反馈！

没太仔细看 mtproto 的实现，是在 client hello 里携带签名信息吗？ 基于 client 主动签名的算法无法防止重放攻击，只有 challenge-response 形式的验证可以。

我的一些想法可以参考这里： https://www.ihcblog.com/a-better-tls-obfs-proxy/

是的，签名中可以夹带时间戳，可以避免重放，MTProto也这样子做了

MTProto不仅在Server Side做数据包校验，Client Side也有数据包校验，避免中间盒探测客户端，MTProto FakeTLS的协议设计具有抗探测和抗重放的性质，对整包进行保护，如果中间盒进行重放，探测等操作，他会回落到真服务器，从而中间盒无法判断是否为代理服务器。

整包保护的好处就是，只要修改了一处，就会被发现。这点使中间盒无法破译TLS内流量，重放无法得到TLS内明文数据，探测会被回落。TLS 1.3对Server Hello后面全部加密保护，所以中间盒没有办法判断证书有效性，唯一的方法就是探测。

MTProto FakeTLS已经完全实现了伪装源服务器，且中间盒探测得到的证书为可信证书，从而可以绕过证书检测。

我很好奇开发者有没有研究过TLS的RFC？只有ClientHello去探测并不能得到什么有效数据吧，都没法发TLS 1.3的Encrypted Client Hello Done

而且不说别的，MTG的FakeTLS实现，认证字段做了一次性处理的，只能用一次，然后会被记录，第二次相同的就会被回落

如果您有telegram的话，最好留一下，拿telegram交流更方便

[ArcCal]

大佬们，Shadow-TLS不用docker部署可以吗，求分享示例配置文件

[ihciah]

If you don't know what you are doing, please close this issue.

MTProto FakeTLS在TLS ClientHello中使用secret进行hmac，将hash值填充在tls.random字段中，服务器可以在clienthello中进行判断，验证客户端有效性，但是依旧被识别，这种方式已经过时了

感谢反馈！
没太仔细看 mtproto 的实现，是在 client hello 里携带签名信息吗？ 基于 client 主动签名的算法无法防止重放攻击，只有 challenge-response 形式的验证可以。
我的一些想法可以参考这里： https://www.ihcblog.com/a-better-tls-obfs-proxy/

是的，签名中可以夹带时间戳，可以避免重放，MTProto也这样子做了

时间戳并不能完全防御重放，多大的差异会被认为合理呢？如果是做类似以前ss的一次性认证的做法，在server侧记录状态保证每个包的唯一性，中间人完全可以做在线的攻击，即先行发送一次截获的client hello包。

Anyway，我认为你说的FakeTLS只是解决了流量认证和TLS包装的问题，它可以应付普通的流量分析，骗过wireshark，但缺乏对主动检测的应对方式。同时，模拟的TLS握手在实现细节上可能总会有点特征，直接转发可以低成本地避免这些潜在问题。

[ihciah]

大佬们，Shadow-TLS不用docker部署可以吗，求分享示例配置文件

可以 ./shadow-tls --help，./shadow-tls client --help，./shadow-tls server --help 看到参数说明。
也可以用 docker-compose 文件，对照 entrypoint 脚本看怎么传递的。

If you don't know what you are doing, please close this issue.

MTProto FakeTLS在TLS ClientHello中使用secret进行hmac，将hash值填充在tls.random字段中，服务器可以在clienthello中进行判断，验证客户端有效性，但是依旧被识别，这种方式已经过时了

感谢反馈！
没太仔细看 mtproto 的实现，是在 client hello 里携带签名信息吗？ 基于 client 主动签名的算法无法防止重放攻击，只有 challenge-response 形式的验证可以。
我的一些想法可以参考这里： https://www.ihcblog.com/a-better-tls-obfs-proxy/

是的，签名中可以夹带时间戳，可以避免重放，MTProto也这样子做了

时间戳并不能完全防御重放，多大的差异会被认为合理呢？如果是做类似以前ss的一次性认证的做法，在server侧记录状态保证每个包的唯一性，中间人完全可以做在线的攻击，即先行发送一次截获的client hello包。

Anyway，我认为你说的FakeTLS只是解决了流量认证和TLS包装的问题，它可以应付普通的流量分析，骗过wireshark，但缺乏对主动检测的应对方式。同时，模拟的TLS握手在实现细节上可能总会有点特征，直接转发可以低成本地避免这些潜在问题。

MTProto确实有一个握手问题，不过足够防御主动探测了，中间盒拿到clienthello并没有办法验证证书有效性，这点已经足够。

中间盒识别报告

已经有内鬼指出ShadowTLS已经被识别