dev4u

> @dev4u What kind of custom header do you have in mind? Should subsequent reply still be random gibberish? Maybe instead of adding an option to allow `ReplyWithGibberish` to have...

> @dev4u, my testbed has been running for 2 weeks. Haven't noticed anything like what you described. Actually I have a doubt about that. Such behavior will definitely compromise any...

@sh4run 我见过有人做过一个这样的方案，跟你这个有点像，可以了解、参考一下： - iptables设定只允许白名单连接ss端口。 - 设定如果接到大尺寸包(mtu)的icmp请求，自动添加客户端到白名单。 - 如果收到的icmp不是大尺寸的，忽略请求。 - ss客户端连接前，先发一个大尺寸包的icmp请求到ss服务器，发了icmp后再建立连接。 - ……

> For example, the traffic over a Shadowsocks TCP port looks nothing like TLS. But if you configure your server to fallback to a TLS server, probing would determine the...

> @dev4u Fallback has been implemented in database64128/shadowsocks-go@bfe027008ad42b2c1434ad13a85a7d544cd5b302, and can be enabled by specifying an `"unsafeFallbackAddress"` in server config. 收到！同时我也发现，你紧接着也commit了返回自定义头部数据的功能💪。 对此，我也有一个疑问一个建议： - 你的ss服务端，能否与rust的客户端(2022协议)很好兼容工作？ - 建议如果设置了`unsafeFallbackAddress`，在启动的时候是否有必要先预请求一下，验确认设置的地址是有效、可用作fallback(更短的超时时间仍正常工作、又或者须指定是loopback地址…避免慢回放)？ 功能的雏形是出来了，希望有关注的小伙伴们，别不小心又跑偏了。

你在方案中加入了用证书做安全手段，这个我觉得是不错的做法，但仍需要通过时间来验证有没短板。 咱们静下来想一下，其实不难发现你提到的问题，在现有的网络环境下，是无解的，该干扰还是会被干扰。 从你的测试反馈来看，我觉得是个幸存者偏差。gfw把你的端口，当作ss服务来刺探处理，而你的代码ss请求又不感冒而避开了。加上你的数据样本少得还没引起gfw的关注，gfw还不想对你的流量做学习。

咱们换种思路。 你描述那么多优点，其实我想知道，如果你是gfw，你可以用什么手段来干扰你的数据？你的协议其实跟ss已经没有半毛钱关系，现有的策略，为什么会觉得对你的sss仍有效呢？ 同时我也交流一些我对gfw的心得看法，可能有点跑题，不中听当我瞎掰。 gfw已经从单一通过数据特征分析，转变为通过立体行为来分析、判定流量的机制。 举个例子，一个服务，周期性产生流量，流量长度一致且不大。这种流量一般是心跳包或者检测包。对于gfw来说，根本不用理会里面是什么数据。 譬如一个端口，请求ip多是原生，且分布地域范围又比较集中、固定，单次流量大小集中分布在一个范围，这种会认为是企业内的应用可能性较大。 我只是举例子，不用对号入座。

这个机制和OTA有什么不同吗？

@rprx 我问跟OTA有什么区别，意思是我认为你这种想法，会为ss的通讯带来了特征和爆破点。 特征不多说了。 引入的爆破点在于，客户端怎么知道，返回的密钥是中间人告诉他的？还是真实服务端告诉他？ 此处是不是应该有个主密钥，来验证这个信息？主密钥从哪来……是不是又回到ss的原点？ 我承认ss仍有不足的地方，但我相信这一切都会好起来的。

> @dev4u > > 所以，会带来什么特征？ > > 初始密钥由 SSH/TLS 可信通道传输，而新的密钥是 AEAD 解密出来的，又有什么问题？ 如你前面所说： “若要实现这个机制，明文 TCP 代理协议结构只需一处小改动：返回的数据前加一个字节代表新密钥长度，0 代表无新密钥” “由于只判断第一个包，所以代价很低” 有条金玉良言：绝不要让密码在“空中”传播。