PoC: 协议探测风险

[ghost]

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

[H1JK]

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

[ghost]

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/

[ghost]

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也这样子做了

[ghost]

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

[ghost]

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

[ghost]

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

[ghost]

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

[ghost]

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

[ghost]

如果您有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 脚本看怎么传递的。

[ghost]

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并没有办法验证证书有效性，这点已经足够。

[ghost]

中间盒识别报告

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

[H1JK]

中间盒识别报告

已经有内鬼指出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.

[H1JK]

btw, this so-called "内鬼" is suspicious.
Do you think psychological warfare is also part of GFW's work?

[ghost]

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.

[H1JK]

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.

[ghost]

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.

[ghost]

Suggested Reference Paper “Parrot Is Dead”

[H1JK]

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

[ghost]

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.

[H1JK]

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.

[ghost]

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.

[ghost]

The difference between shadow TLS and mtproto is that shadow TLS handshakes with the real server and supports tls 1.2

[ihciah]

中间盒识别报告

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

这个图在 v2 版本出来之前就有了。v1 版本确实很容易识别，只是一个可以私下小规模用用的简单 tls 封装。

[ghost]

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连接来精准识别客户端 从而对其封杀

[vcheckzen]

你给出可复现的探测步骤和完整代码，说其它的都没用

[ihciah]

重定向TCP连接理论上确实会有效。 当前 v2 版本协议的设计是 client 无条件切换数据源（先握手后发送自己加密的数据），server 侧有条件切换（通过鉴权后切换）。而要防御这种攻击只能增加 client 对 server 侧的鉴权，这要求 server 侧能够隐蔽发送证明身份的数据。 如果保持现有的交互行为不变，这要求我们能够将证明性的信息隐藏在 server 转发回去的数据中，而这个事情做不到（如果 hack tls 协议的话可能可行）。 如果改变交互行为，比如通过增加交互来做双向鉴定，本身会成为一种新的特征，故不采用这种方式。 所以我想法是当前协议设计不具备对重定向TCP连接防御的能力，这可能是代理握手数据这种做法的先天缺陷；但是我认为实施这种攻击成本较高（相比离线分析和主动探测），问题不大。长期的话会仔细研究下 tls 协议，看下能否在中继的握手过程中携带信息。

[ghost]

重定向TCP连接理论上确实会有效。 当前 v2 版本协议的设计是 client 无条件切换数据源（先握手后发送自己加密的数据），server 侧有条件切换（通过鉴权后切换）。而要防御这种攻击只能增加 client 对 server 侧的鉴权，这要求 server 侧能够隐蔽发送证明身份的数据。 如果保持现有的交互行为不变，这要求我们能够将证明性的信息隐藏在 server 转发回去的数据中，而这个事情做不到（如果 hack tls 协议的话可能可行）。 如果改变交互行为，比如通过增加交互来做双向鉴定，本身会成为一种新的特征，故不采用这种方式。 所以我想法是当前协议设计不具备对重定向TCP连接防御的能力，这可能是代理握手数据这种做法的先天缺陷；但是我认为实施这种攻击成本较高（相比离线分析和主动探测），问题不大。长期的话会仔细研究下 tls 协议，看下能否在中继的握手过程中携带信息。

如果直接转发真的服务器TLS握手，则不能修改任何数据，如果修改了数据，则会握手失败，hack tls依然没有办法解决此问题，客户端与服务器协商加密不符，服务器无法解密数据包，则会抛出Alert

[ghost]

重定向TCP连接理论上确实会有效。 当前 v2 版本协议的设计是 client 无条件切换数据源（先握手后发送自己加密的数据），server 侧有条件切换（通过鉴权后切换）。而要防御这种攻击只能增加 client 对 server 侧的鉴权，这要求 server 侧能够隐蔽发送证明身份的数据。 如果保持现有的交互行为不变，这要求我们能够将证明性的信息隐藏在 server 转发回去的数据中，而这个事情做不到（如果 hack tls 协议的话可能可行）。 如果改变交互行为，比如通过增加交互来做双向鉴定，本身会成为一种新的特征，故不采用这种方式。 所以我想法是当前协议设计不具备对重定向TCP连接防御的能力，这可能是代理握手数据这种做法的先天缺陷；但是我认为实施这种攻击成本较高（相比离线分析和主动探测），问题不大。长期的话会仔细研究下 tls 协议，看下能否在中继的握手过程中携带信息。

实际上对此流量进行攻击成本很低，如果用户真的是访问该SNI的，重定向TLS流量客户端不会有任何异常感知，原本就是访问真服务器，重定向的也是一个真服务器，都是真服务器则没有任何问题。可以完整的进行TLS握手。这种攻击方式对于分析Shadowsocks和VMess以及TLS流量的开销还要低。

[ghost]

甚至可以在家用路由器进行这个攻击，通过iptables

最简单的复现方法就是 直接使用ShadowTLS客户端对真服务器进行连接，直接抓包即可

[ihciah]

如果直接转发真的服务器TLS握手，则不能修改任何数据，如果修改了数据，则会握手失败，hack tls依然没有办法解决此问题，客户端与服务器协商加密不符，服务器无法解密数据包，则会抛出Alert

嗯，不确定是不是可以 hack 一下 client 侧的 tls 实现。不过感觉可能性不大，因为 server 侧的行为还要能兼容正常 tls client。

实际上对此流量进行攻击成本很低，如果用户真的是访问该SNI的，重定向TLS流量客户端不会有任何异常感知，原本就是访问真服务器，重定向的也是一个真服务器，都是真服务器则没有任何问题。可以完整的进行TLS握手。这种攻击方式对于分析Shadowsocks和VMess以及TLS流量的开销还要低。

实施这个攻击就是在主路上搞事情了，常规的分析都是旁路的；并且实施这个操作需要定制性地针对本协议做，套不上其他分析框架，所以我觉得可能成本会比较大。当然我也不知道中间人会不会这个干，以及它做这个事的代价。

[ghost]

如果直接转发真的服务器TLS握手，则不能修改任何数据，如果修改了数据，则会握手失败，hack tls依然没有办法解决此问题，客户端与服务器协商加密不符，服务器无法解密数据包，则会抛出Alert

嗯，不确定是不是可以 hack 一下 client 侧的 tls 实现。不过感觉可能性不大，因为 server 侧的行为还要能兼容正常 tls client。

实际上对此流量进行攻击成本很低，如果用户真的是访问该SNI的，重定向TLS流量客户端不会有任何异常感知，原本就是访问真服务器，重定向的也是一个真服务器，都是真服务器则没有任何问题。可以完整的进行TLS握手。这种攻击方式对于分析Shadowsocks和VMess以及TLS流量的开销还要低。

实施这个攻击就是在主路上搞事情了，常规的分析都是旁路的；并且实施这个操作需要定制性地针对本协议做，套不上其他分析框架，所以我觉得可能成本会比较大。当然我也不知道中间人会不会这个干，以及它做这个事的代价。

防火墙已经具备在主路上进行攻击的能力，白名单IP的方法也已经失效了。防火墙是流量的必经之地，防火墙可以伪造ip，甚至可以调换数据包

参考 https://github.com/shadowsocks/shadowsocks-org/issues/183

[ghost]

如果直接转发真的服务器TLS握手，则不能修改任何数据，如果修改了数据，则会握手失败，hack tls依然没有办法解决此问题，客户端与服务器协商加密不符，服务器无法解密数据包，则会抛出Alert

嗯，不确定是不是可以 hack 一下 client 侧的 tls 实现。不过感觉可能性不大，因为 server 侧的行为还要能兼容正常 tls client。

实际上对此流量进行攻击成本很低，如果用户真的是访问该SNI的，重定向TLS流量客户端不会有任何异常感知，原本就是访问真服务器，重定向的也是一个真服务器，都是真服务器则没有任何问题。可以完整的进行TLS握手。这种攻击方式对于分析Shadowsocks和VMess以及TLS流量的开销还要低。

实施这个攻击就是在主路上搞事情了，常规的分析都是旁路的；并且实施这个操作需要定制性地针对本协议做，套不上其他分析框架，所以我觉得可能成本会比较大。当然我也不知道中间人会不会这个干，以及它做这个事的代价。

现实的情况是 如果修改TLS的trafficSecret密钥计算方式，那么该PoC依然有效，如果要修改TLS数据包，则握手失败，而且主动探测也会TLS握手失败。

[ghost]

TLS的trafficSecret密钥计算方法是客户端和服务器收到的所有包进行hmac算法，如果修改必定客户端握手失败

[ihciah]

我说的成本主要体现在：

1. 开发成本高，当前的分析系统需要做较大改动
2. 风险成本高，因为在操纵主路数据
3. 发现成本高，互联网上几乎都是 tls 流量，即便是取 0.01% 做攻击，其 cost 都是巨大的(计算成本和风险成本)，并且大概率还找不到

[ghost]

我说的成本主要体现在：

1. 开发成本高，当前的分析系统需要做较大改动
2. 风险成本高，因为在操纵主路数据
3. 发现成本高，互联网上几乎都是 tls 流量，即便是取 0.01% 做攻击，其 cost 都是巨大的(计算成本和风险成本)，并且大概率还找不到

是这样的，但是对比流量大数据就可以知道，当一个sni对着一个新ip发送tls流量，就有风险可以去探测

[ghost]

防火墙一旦结合历史流量数据和客户端探测，基本上可以实现精准封杀

[ghost]

防火墙一旦结合历史流量数据和客户端探测，基本上可以实现精准封杀

目前似乎没有协定可以躲过。但你可以买买很多IP、设定多个不同的SNI、设定分流。

那样子使用者成本会暴涨，我不确定中间盒是否会结合历史数据，如果结合了历史数据的话

我用Google DNS举例 这片区域访问Google DNS的流量目标ip都是8.8.8.8和8.8.4.4 这个时候出现了一个新的连接sni为dns.google 而目标ip不是上面两个的话 风险会很高

而且我不能确定中间盒是否有网站IP对照表 很多大厂的网站都是公开其IP地址范围的 如果网站使用CDN了 那么可以对比CDN的IP范围 ASN的话同理

比如说 deb.debian.org 就是 Fastly提供的 CDN

[JarmoHu]

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连接来精准识别客户端 从而对其封杀

发表一点个人的浅薄见解，如果上述方案一旦被启用，是不是可以用来攻击正常ip。比如我用shadowtls直接指向一个正常ip，然后服务器关闭此链接，然后就这个IP被墙盯上了，就失去了一个正常的网站？

[ihciah]

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连接来精准识别客户端 从而对其封杀

发表一点个人的浅薄见解，如果上述方案一旦被启用，是不是可以用来攻击正常ip。比如我用shadowtls直接指向一个正常ip，然后服务器关闭此链接，然后就这个IP被墙盯上了，就失去了一个正常的网站？

笑死，这波在大气层！

[ghost]

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连接来精准识别客户端 从而对其封杀

发表一点个人的浅薄见解，如果上述方案一旦被启用，是不是可以用来攻击正常ip。比如我用shadowtls直接指向一个正常ip，然后服务器关闭此链接，然后就这个IP被墙盯上了，就失去了一个正常的网站？

不会啊，攻击的原理就是让服务器关闭，而真的shadow tls服务器是不会关闭的，会执行转发，这就是差异所在

[ghost]

浏览器到shadow tls服务器 正常握手 客户端到shadow tls服务器 正常握手

浏览器到真服务器 正常握手 客户端到真服务器 服务器抛出异常

[3andne]

@CoiaPrant233 Would you like to take a look at this by any chance? https://github.com/ihciah/shadow-tls/issues/66 This might mitigate the issue mentioned in this discussion.

[gaukas]

This could be a general issue and might introduce higher collateral damage than we have expected. Please refer to our accepted work at FOCI'23: Chasing Shadows: A security analysis of the ShadowTLS proxy

In appendix section, we have discussed the certain vulnerability and included some superficial evaluations.

[ghost]

Initially, there seems to be no problem.

[ghost]

This could be a general issue and might introduce higher collateral damage than we have expected. Please refer to our accepted work at FOCI'23: Chasing Shadows: A security analysis of the ShadowTLS proxy

In appendix section, we have discussed the certain vulnerability and included some superficial evaluations.

Please add the source description to A.1, thank you.

[ghost]

@CoiaPrant233 Would you like to take a look at this by any chance? #66 This might mitigate the issue mentioned in this discussion.

I have found some problems that I will consider disclosing publicly when gaukas completes the relevant sources in the paper. It is unrealistic to add or modify in the TLS handshake, and it should be abandoned.