Shadowsocks-windows: 导入Android上的URL失败

[thelastlin]

版本

4.0.4.0(commit:057b148)

环境

Win10 x64 16241, VS2015 Update3, .Net Framework 4.7.02505

描述

PC版分享的URL是这样的：
ss://bWV0aG9kOnBhc3N3b3JkQDczLjgwLjczLjgwOjQ1Mwo=#thequickbrownfox _(更正:注释没有编码)_
而Android版(v4.1.8)分享的URL是这样的：
ss://[email protected]:453#jumpsoverthelazydog _(同上)_
PC版不能导入Android版分享出来的URL。

[wongsyrone]

这种URL定义太傻了，如果我是GFW管理者直接干掉105.112.105.112这个IP了，或者反查一下对应的VPS地址段，然后全部加入IP block list，我根本不关心你设置的加密和密码

[thelastlin]

Android版URL定义确实奇怪。
不过要和谐的话这两种方法都跑不了吧...
假如我是GFW管理者，我也可以先解base64再和谐掉对应的IP段啊

[celeron533]

是否暴露endpoint并不是问题，毕竟base64可以随意解码（更正：暴露endpoint可以直接表明整个字符串有特殊作用）
不是很清楚为什么android版不把地址一起编码掉。这种编码一半明文一半在后续处理的时候会稍有麻烦。难道是为了靠这个来人眼识别不同的服务器？

ss://bWV0aG9kOnBhc3N3b3JkQDczLjgwLjczLjgwOjQ1Mwo=
method:[email protected]:453

ss://bWV0aG9kOnBhc3N3b3JkCg==@73.80.73.80:453
method:password

[breakwa11]

谁定义的这种URL格式

[thelastlin]

@breakwa11
翻看了一下相关的issue记录：

在Dec 30 2016中就提到了新URL格式，并且@Mygod和@madeye似乎达成了一致使用半编码半明文的URL格式。

[celeron533]

@thelastlin 提供的线索 https://github.com/shadowsocks/shadowsocks-org/issues/27
SIP002
这就尴尬了

[wongsyrone]

其实是为了与rfc保持一致，不过他们可能忘记了这个不是普通的url，这个实际上就是你自己配置文件的变体。这么搞无异于把本来应该mask掉的信息直接分享出来。

我建议有脑子的人不要实现这个

[wongsyrone]

暴露endpoint对ss是致命的，加密的目的是将这个endpoint看起来不可疑。各种探测是为了证明它是代理，如果已经知道了这个结论，直接封ip没有异议，毕竟前缀已经告诉他这个是ss了，也就是先有结论，那么过程完全不重要

[breakwa11]

厉害厉害，这格式太厉害了，SS大神们的想法和我这种一般人果然不同

[thelastlin]

如果传递时不注重保密的话，这两种编码方式对GFW无区别。传递配置的保密工作应由用户自行完成。

[celeron533]

暴露endpoint对ss是致命的，加密的目的是将这个endpoint看起来不可疑。各种探测是为了证明它是代理，如果已经知道了这个结论，直接封ip没有异议，毕竟前缀已经告诉他这个是ss了，也就是先有结论，那么过程完全不重要

想想也有道理，开个脑洞。假设在网页中出现了如下内容，被邪恶的Bot看到了：
ss://bWV0aG9kOnBhc3N3b3JkQDczLjgwLjczLjgwOjQ1Mwo=
Bot: ss开头，很明显，解码，封IP。
ss://[email protected]:453
Bot: ss开头，很明显，解码，封IP。

但如果拿掉协议头：
bWV0aG9kOnBhc3N3b3JkQDczLjgwLjczLjgwOjQ1Mwo=
Bot: 这似乎是一张内嵌图片？可以解码后看看。但由于现在这种html直接嵌图很普遍，全网页都解码一遍代价高。
[email protected]:453
Bot: 前面没看懂，但是后面有IP匹配，这个地址很可疑。解码试试？

当然，更好玩的是多次base64编码（或者是编码解码比较耗时间的算法，让爆破取样效率降低）
原文 method:[email protected]:453
标准格式ss://bWV0aG9kOnBhc3N3b3JkQDczLjgwLjczLjgwOjQ1Mw==
再来一次c3M6Ly9iV1YwYUc5a09uQmhjM04zYjNKa1FEY3pMamd3TGpjekxqZ3dPalExTXc9PQ==
还来YzNNNkx5OWlWMVl3WVVjNWEwOXVRbWhqTTA0ellqTkthMUZFWTNwTWFtZDNUR3BqZWt4cVozZFBhbEV4VFhjOVBRPT0=
至少bot一上手是猜不到这个是什么东西的

---

另一方面，服务器主人要管理好自己的接入方式，这个ss://地址理应只在自己可信任的区间传播而不是公开给大众

[thelastlin]

偶然间发现了有关SIP002的页面。其中有一条:

Currently, SIP002 is still an optional feature unless the client supports SIP003 plugins.

这样来说，因为PC版看上去还没有关于SIP003插件的计划，不兼容SIP002也很正常。

[celeron533]

可以看看这个pull request
SIP002 and SIP003 support. #1298

[thelastlin]

之前略微测试了下这个pull request
SIP002应该没问题，SIP003还没条件进行测试。

[thelastlin]

Fixed via 71120e5