prevent sniffing when replay attack happen

[8x8-64]

目前发现中间人经常给服务器发虚假来源地址的数据包，其中一种是replay attack，把客户端发给服务器或者服务器发给客户端的某次连接第1个数据包，重新发给服务器。可以预见的结果是服务器都会通过验证，如果是收到客户端发来的包，会返回同样的结果，如果是收到发给客户端的包，解码后一般地址类型字节是错的（正确的只有3种情况），会出错断开连接。只要密码没修改，重放攻击的结果一般都是一样的。从记录看，重放1秒前到1天内的数据包都有，一般只重放1次，但采取应对措施后（我改了服务器程序），有时达7次

出现这个问题的原因是没有对salt做限制，比如v2ray，加了时间要求，以及服务器端salt其实是客户端提供的，在120秒内拒绝重复的salt就可以防止重放攻击探测。

防止重放的一个方法，不需要更改ss协议格式，只是在程序实现上，可以通过插件（客户端和服务器端都要开启）对subkey的生成增加步骤，比如确定最近30秒内一个整时间点，加入到输入中（即约定的隐藏时间信息）。程序保存30秒内通过验证连接的salt（包括服务器自身发给客户端的），并拒绝重复的。对于跨时间点情况，同时验证下一个整点或当前整点subkey。到下一个30秒后，上一个30秒内保存的salt就可以丢弃了。

[madeye]

IV replay resist is already part of modern implementation of shadowsocks, with the help of a ping-pong bloom filter.

Search the issue tracker for previous discussions.

[8x8-64]

libev版用了布隆过滤器标记salt，这个本质上是节约了存储salt的空间，还是需要所有salt都记录下来。我提出的加时间信息，本质也是为了节约存储，不记录近期以外的salt，而记录近期的salt也可以用布隆过滤器，这样可以把时间范围放的更宽。

libev版有2个布隆过滤器，其中1个满了之后，就释放空间用另1个空的，在切换的时候不就把之前的记录都丢弃了？这样切换前很近一段时间的salt拿来重放攻击就不知道了，哪怕是上1秒才用过的

[madeye]

Actually not, when ping is full, pong is reset. All the new salt will be stored in pong and all recent salts are still in ping.

That's why we call it a ping-pong bloom filter.

[riobard]

Timestamp-based anti-replay would require protocol changes and thus changes to both clients and servers, making it a hard sale for Shadowsocks due to the vast number of deployed clients. Bloom filter-based approach does not require changes to the protocol and that's why it's adopted.

[8x8-64]

https://github.com/cbeuw/GoQuiet
我的做法和goquiet的防止重放攻击理念基本相同