RPRX
@fortuna On the other hand, if this ever-changing key is considered the long-term key, then indeed we achieved the goal of forward secrecy: protects past sessions against future compromises of...
Blocked @QuantumGhost 说一下原因，这个人的行为一直是对我的观点按 thumbs down，并对相反的观点按 thumbs up 从 #177 到这里一直是这样，无论两边的观点本身如何，且他无法给出适当的理由 只能眼不见为净了。
@xiaokangwang 先前我已经提了一个 **改协议** 来实现前向安全等更高级特性的方案 #177 ，你提到的“改进的方法”与我之前已经提过的 #177 所实现的事情没有本质区别，反而更加复杂。但是当时他们不愿意改协议，所以这里的 #178 是以 **不改协议** 且同样不引入长期额外信道为前提的，基于此，目前没有发现更好的想法了。所以首先需要记住这些限制，然后说回想法本身：1.每个用户的密码变化规则都不同，且密码被复用的超低概率不会造成问题。2.旧密码未被摧毁的问题确实考虑过且值得关注，一般来说新密码会覆写硬盘上的旧密码，或者至少擦除旧密码，实现上需要参考一些现有的数据安全方案。最后还是重新提一下，这里是种种限制之下的方案，对比时不能忘记这一点。 然而鉴于前几天我又提出了 #183 和 #184 ，改协议或更加依赖 TLS 已不可避免。
其实只会阻断这类协议：**未知流量、0-RTT、有重放过滤器**，~~听起来是不是很熟悉？而且并没有封你，是你自己封了自己。~~
@NutterChen @DuckSoft 正常的服务通常有握手鉴权机制，并且因此没有重放过滤器，即使某中间人无法识别给这么操作一波，基本上不会受影响。 而这些代理是不能有握手鉴权机制的，否则公开后会成为强特征。所以这是一个死局，还可以按比例干扰，非常恶心。
对了，防重放机制不一定都无限读，~~不然这也是强特征。~~
可以用 [Xray-core](https://github.com/XTLS/Xray-core) 的 TPROXY + sniffing + Freedom 改改代码来模拟出这种攻击。
感谢 @gfw-report 进行详尽的测试，我的补充如下： 1. 若主要针对现有的 Shadowsocks 协议，则 **50 bytes** 足以包含一个有效的 length 加密块，我推测这应该会影响 Outline server。 2. 我认为攻击者无需给原连接增加显著的延迟，因为只需 **快一步** 即可，即攻击者的 IP Packet 始终具有更高的发送优先级。 3. 这种方式对 VMess 等协议也是 **通杀的**，所以攻击者实施前仅需评估附带伤害，它应该是微不足道的，目前需要进一步验证。
@gfw-report 1. 是的，此前我看过 ss-libev 的代码。所以我推测 50 bytes 时会受到影响的是 **Outline server**（因为它是单端口多用户） 2. 不需要 `0.28s`，我的意思是两个连接应该是 **并行的**，而不是阻塞的，这样更具实用性
@fortuna I'm contacting you via Keybase