ihc童鞋@提不起劲

> 排除SSR协议的问题,换SS依然不能用0.21正常转发。 异常主要表现为流量没有即时转发到目的地，用Clash的延迟测试 访问 gstatic.com 或者其他网站啥的，只有部分请求到达了SS后端（类似高丢包的状态），但是shadow-tls两端的日志均为正常转发，应该有可能是sni的问题，目前不太清楚用啥sni能tls1.2 > > 开了个临时环境做了下 tcpdump: https://mega.nz/file/tp8m3QoK#_qJT05BWF8jkWU7ODUDL_9IFAbInYa5CJnVAW2uzmaA 看了下包，没太看出来问题233 可以用腾讯云的试下，不过我这边用 www.apple.com.cn 也表现正常的。。

不会写移动端，所以目前暴露的接口是二次包装流量而不是自己做代理协议。 可以在国内部署一个客户端，之后用手机走原协议连。

Why disable? If you set a widely used password(for example empty password) then it can be detected.

> 大佬们，Shadow-TLS不用docker部署可以吗，求分享示例配置文件 可以 `./shadow-tls --help`、`./shadow-tls client --help`、`./shadow-tls server --help` 看到参数说明。

> > 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...

> > > > If you don't know what you are doing, please close this issue. > > > > > > > > > MTProto FakeTLS在TLS ClientHello中使用secret进行hmac，将hash值填充在tls.random字段中，服务器可以在clienthello中进行判断，验证客户端有效性，但是依旧被识别，这种方式已经过时了 > >...

> 大佬们，Shadow-TLS不用docker部署可以吗，求分享示例配置文件 可以 `./shadow-tls --help`，`./shadow-tls client --help`，`./shadow-tls server --help` 看到参数说明。 也可以用 docker-compose 文件，对照 entrypoint 脚本看怎么传递的。

> [中间盒识别报告](https://postimg.cc/vxnN0t1v) > > 已经有内鬼指出ShadowTLS已经被识别 这个图在 v2 版本出来之前就有了。v1 版本确实很容易识别，只是一个可以私下小规模用用的简单 tls 封装。

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

> 最新测试版在插件选择 shadow-tls 设置。 求个测试版入口🌚