shadow-tls
shadow-tls copied to clipboard
ihciah
PoC: 协议探测风险
If you don't know what you are doing, please close this issue.
MTProto FakeTLS在TLS ClientHello中使用secret进行hmac，将hash值填充在tls.random字段中，服务器可以在clienthello中进行判断，验证客户端有效性，但是依旧被识别，这种方式已经过时了
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后面全部加密保护，所以中间盒没有办法判断证书有效性，唯一的方法就是探测。
我很好奇开发者有没有研究过TLS的RFC？只有ClientHello去探测并不能得到什么有效数据吧，都没法发TLS 1.3的Encrypted Client Hello Done
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握手在实现细节上可能总会有点特征，直接转发可以低成本地避免这些潜在问题。
大佬们，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已经被识别
There are no words that explicitly indicates that these connections are using ShadowTLS, but people inferred from the subsequent behavior that this is ShadowTLS.
This is the ShadowTLS v1 version, it only does a simple handshake and then turns to a simple stream without obfuscation, so it may be recognized.
Then that's why it needs a obfs to make it behave like a true TLS connection.
btw, this so-called "内鬼" is suspicious.
Do you think psychological warfare is also part of GFW's work?
btw, this so-called "内鬼" is suspicious. Do you think psychological warfare is also part of GFW's work?
If you don't believe it, fine, my advice is if it's true, then it's terrible.
btw, this so-called "内鬼" is suspicious. Do you think psychological warfare is also part of GFW's work?
If you don't believe it, fine, my advice is if it's true, then it's terrible.
I believe it can find ShadowTLS v1, but there are too many mistakes in that picture, even typo problems.
It looks like a PPT, as someone said.
btw, this so-called "内鬼" is suspicious. Do you think psychological warfare is also part of GFW's work?
If you don't believe it, fine, my advice is if it's true, then it's terrible.
I believe it can find ShadowTLS v1, but there are too many mistakes in that picture, even typo problems. It looks like a PPT, as someone said.
This picture was released at the end of August, and its authenticity is unknown, but we can confirm that shadow TLS only has a TLS handshake, and it also belongs to FakeTLS, which is different from the real TLS.
btw, this so-called "内鬼" is suspicious. Do you think psychological warfare is also part of GFW's work?
If you don't believe it, fine, my advice is if it's true, then it's terrible.
I believe it can find ShadowTLS v1, but there are too many mistakes in that picture, even typo problems. It looks like a PPT, as someone said.
This picture was released at the end of August, and its authenticity is unknown, but we can confirm that shadow TLS only has a TLS handshake, and it also belongs to FakeTLS, which is different from the real TLS.
This picture is for ShadowTLS v1. Currently he hasn't published any picture about v2 so we can't know if v2 is also weak like v1. But we have confidence that v2 should work better than before.
Suggested Reference Paper
btw, this so-called "内鬼" is suspicious. Do you think psychological warfare is also part of GFW's work?
If you don't believe it, fine, my advice is if it's true, then it's terrible.
I believe it can find ShadowTLS v1, but there are too many mistakes in that picture, even typo problems. It looks like a PPT, as someone said.
This picture was released at the end of August, and its authenticity is unknown, but we can confirm that shadow TLS only has a TLS handshake, and it also belongs to FakeTLS, which is different from the real TLS.
This picture is for ShadowTLS v1. Currently he hasn't published any picture about v2 so we can't know if v2 is also weak like v1. But we have confidence that v2 should work better than before. You are right, v2 work better than v1, but it's still different from the real TLS.
But in the other hand, ShadowTLS is designed to bypass SNI whitelist at the beginning. There are different problems encountered at this time, and there will always be trade-offs here.
But in the other hand, ShadowTLS is designed to bypass SNI whitelist at the beginning. There are different problems encountered at this time, and there will always be trade-offs here.
No problem, MTProto FakeTLS has also done this, I don't think it's necessary to continue to study this.
The difference between shadow TLS and mtproto is that shadow TLS handshakes with the real server and supports tls 1.2
已经有内鬼指出ShadowTLS已经被识别
这个图在 v2 版本出来之前就有了。v1 版本确实很容易识别，只是一个可以私下小规模用用的简单 tls 封装。
https://telegra.ph/%E6%8A%A5%E5%91%8A-%E4%B8%AD%E9%97%B4%E7%9B%92%E5%A6%82%E4%BD%95%E8%AF%86%E5%88%AB%E4%BB%A3%E7%90%86%E6%B5%81%E9%87%8F-10-17
新鲜的报告和PoC 防火墙完全可以重定向TCP连接来精准识别客户端 从而对其封杀
重定向TCP连接理论上确实会有效。 当前 v2 版本协议的设计是 client 无条件切换数据源（先握手后发送自己加密的数据），server 侧有条件切换（通过鉴权后切换）。而要防御这种攻击只能增加 client 对 server 侧的鉴权，这要求 server 侧能够隐蔽发送证明身份的数据。 如果保持现有的交互行为不变，这要求我们能够将证明性的信息隐藏在 server 转发回去的数据中，而这个事情做不到（如果 hack tls 协议的话可能可行）。 如果改变交互行为，比如通过增加交互来做双向鉴定，本身会成为一种新的特征，故不采用这种方式。 所以我想法是当前协议设计不具备对重定向TCP连接防御的能力，这可能是代理握手数据这种做法的先天缺陷；但是我认为实施这种攻击成本较高（相比离线分析和主动探测），问题不大。长期的话会仔细研究下 tls 协议，看下能否在中继的握手过程中携带信息。