Refactor: new Shadowsocks validator

[AkinoKaede]

I think #625 may be fix by this PR.

[gfw-report]

Hi @AkinoKaede,

Thank you for spending efforts trying to fix this problem.

Our testing shows that the problem has not been fixed completely as of this commit 6d87f9cfa9218df02f8057af27de083bc15243c1. Below is how we tested it and you can try to reproduce it yourself:

Open the first terminal to build and run Xray. The config.json is the same as in #625 (comment):

git clone https://github.com/AkinoKaede/Xray-core.git -b refactor-shadowsocks-validator
go build -o xray -trimpath -ldflags "-s -w -buildid=" ./main
./xray < config.json

Open the second terminal to quickly run testings. And you can see:

The server will wait indefinitely when receiving 1 byte of invalid data:

python3 -c "print('a' * 1)" | nc -v localhost 12345

The server will, with some probabilities, either 1) close the connection immediately; or 2) wait indefinitely:

for i in {1..10}; do python3 -c "print('a' * 500)" | nc -v localhost 12345; done 

Looking forward to your patches.

[RPRX]

“读取超时 -> drain with 随机超时”机制应该可以解决上述问题

[moranno]

@AkinoKaede 关于““读取超时 -> drain with 随机超时”机制”可以在你的代码中更新一下吗？感谢感谢！

[AkinoKaede]

@AkinoKaede 关于““读取超时 -> drain with 随机超时”机制”可以在你的代码中更新一下吗？感谢感谢！

抱歉，我没有什么精力和兴趣完成这项工作。BTW，在遭到某些自以为在维护社区的人的勒索后，我觉得我没有必要继续做此类工作。

[moranno]

@AkinoKaede 关于““读取超时 -> drain with 随机超时”机制”可以在你的代码中更新一下吗？感谢感谢！

抱歉，我没有什么精力和兴趣完成这项工作。BTW，在遭到某些自以为在维护社区的人的勒索后，我觉得我没有必要继续做此类工作。

很遗憾听到这个消息。不知 @RPRX 未来有空完成这个机制吗？

[moranno]

@AkinoKaede 关于““读取超时 -> drain with 随机超时”机制”可以在你的代码中更新一下吗？感谢感谢！

抱歉，我没有什么精力和兴趣完成这项工作。BTW，在遭到某些自以为在维护社区的人的勒索后，我觉得我没有必要继续做此类工作。

目前使用1.4.2版的xray，shadowsocks，chacha20加密，无混淆，无插件，每日流量3G左右，最近几天每天都被封一个端口；能否请@AkinoKaede再考虑下更新下代码？我可以付费资助。

[AkinoKaede]

For the first problem that GFW Report reported, Xray need to read 50 bytes to authenticate the users, it is caused by the multi-user feature, and I don't have a good idea to resolve it.
For the second problem, Xray will wait indefinitely until read a random size if the connection is invalid. It was design to avoid probing weakness, and it called Drain. The seed of random size is decided by the users' key and cipher or the timestamp when server received the first connection.

[moranno]

For the first problem that GFW Report reported, Xray need to read 50 bytes to authenticate the users, it is caused by the multi-user feature, and I don't have a good idea to resolve it.
For the second problem, Xray will wait indefinitely until read a random size if the connection is invalid. It was design to avoid probing weakness, and it called Drain. The seed of random size is decided by the users' key and cipher or the timestamp when server received the first connection.

Thank you for the explanation.
It seems outline ss server doesn't have this issue, could you consider to replace the xray core's shadowsocks implement by https://github.com/Jigsaw-Code/outline-ss-server 's code?
https://github.com/Jigsaw-Code/outline-ss-server/blob/master/service/PROBES.md
It has

• multiple users on a single port feature
• updated regularly
• write in Go lang
• active community supported by google

Thanks again for your effort.

[AkinoKaede]

Since there was no maintainer reviewing this Pull Request or commenting on it for a long time, I closed it.

[AkinoKaede]

I reopened it. And try to resolve the conflicts. I don't have enough time to work, so please review it as soon as possible.

[FranzKafkaYu]

time

附议

[yuhan6665]

感谢大佬 测试了似乎可以解决主动探测的问题

[moranno]

复议，感谢大佬！！！
@yuhan6665 能否发个新版？

[FranzKafkaYu]

Well done!Thanks for your hard work! @AkinoKaede @gfw-report @yuhan6665

[AkinoKaede]

Oh, sorry. I found a bug that the header is shorter than 50 bytes in none cipher.

[AkinoKaede]

Oh, sorry. I found a bug that the header is shorter than 50 bytes in none cipher.

Some protocols like SMTP will not work with none cipher.