其实这个要说的少得多，总之就一句话，能用auth_aes128_md5或auth_aes128_sha1的，就直接用这两个，最好不要开启兼容，其它的协议都不建议。但如果要解释的话，这个说来话长，需要一点点说明其它的协议的特性。以下简略说明一下各协议的问题。
首先我们来看原版协议（origin），原版协议有着最少的数据冗余，在没有限制的情况下，必然是原版协议速度最快，这是毫无疑问的。其它的协议的兼容，全是为了兼容原版协议。那既然原版理论上最快为什么不直接用？因为它没有数据完整性校验，无法确认数据是否被篡改，容易被攻击，它也没有做数据包的长度混淆，可以通过数据包长度统计分析检测出来（例如此专利中所说的方案）。当然如果你所在的地区直接使用没有感觉有什么问题，那直接使用就可以了，没有必要考虑后面的。
接着来看原版的OTA协议，这个协议增加了从客户端到服务端单向的完整性校验，于是服务端到客户端的方向还是存在同样的问题，且它也没有做数据包的长度混淆，一样可以通过数据包长度统计分析检测出来。另外此协议并非能抵抗CCA（Chosen ciphertext attack），依然可以通过CCA来确定这是不是OTA协议（通过服务端行为攻击，具体方法这里不说）。
然后再看SSR的auth_sha1和auth_sha1_v2协议，这两协议几乎一样，这两协议都有双向的完整性校验，有数据包的长度混淆，有抵抗重放攻击的能力，但缺点是不能完全抵抗CCA，可使用检测OTA的方法检测出来（不用改动一行代码，但无法区分到底是OTA还是auth_sha1，如要确定，那只要对服务端发向客户端的方向发起CCA攻击即可区分）
再来看看SSR的auth_sha1_v4协议，相对于auth_sha1，在抵抗CCA方面有改进，但依然不是完全抵抗CCA，尽管多增加了长度校验避免服务端行为攻击，但因为校验使用的是CRC32，而CRC32可以通过已知的正确的数据包，再通过同时修改包长度字段和CRC32来伪造出正确的值，所以虽然攻击难度增加了，但并非完全抵抗CCA。不过某防火墙要如此针对性的攻击此协议的可能性非常低，可以认为基本安全，但如果你条件允许，那还是看下面两个协议吧。
最后再看看auth_aes128_md5和auth_aes128_sha1，这两协议在关键的认证数据区使用Encrypt-then-MAC，使其无法CCA，而后续的数据包均使用HMAC，且每个连接的不同数据包用的HMAC的KEY都不一样，之前的攻击方案均失效。对于这个协议我自己还没有想到有效的攻击手段，并且此协议的网络利用率比其它的auth系列协议要高，也是唯一一组抗CCA的协议，所以我推荐大家使用这个协议。不过唯一的缺点是这个协议计算量会比其它的协议要多，代码编写较复杂。关于此协议我写了一个简要的文档说明。
其它花絮：因为auth_aes128_md5协议的前数百个字节不是random的就是HMAC或加密的，总之前面一大堆表面看起来都像是random，所以我曾经试过直接用这个协议裸跑（不使用加密也不使用混淆），结果显示完全能正常使用。但还是不建议大家这么做，毕竟后面还是带着明文的，要是关键字检测会检测到那么后面的话就挂了（但给我的感觉是这个明文关键字检测并不严厉，似乎只针对http, TLS, socks等已知协议）
关于协议就简略讲到这里了（如何攻击这里不讲，否则要列举一堆例子和演示代码，更具体的以后会有机会讲的），有什么问题可补充。
from https://breakwa11.blogspot.ch/2016/11/shadowsocksr.html
---------
首先我们来看原版协议（origin），原版协议有着最少的数据冗余，在没有限制的情况下，必然是原版协议速度最快，这是毫无疑问的。其它的协议的兼容，全是为了兼容原版协议。那既然原版理论上最快为什么不直接用？因为它没有数据完整性校验，无法确认数据是否被篡改，容易被攻击，它也没有做数据包的长度混淆，可以通过数据包长度统计分析检测出来（例如此专利中所说的方案）。当然如果你所在的地区直接使用没有感觉有什么问题，那直接使用就可以了，没有必要考虑后面的。
接着来看原版的OTA协议，这个协议增加了从客户端到服务端单向的完整性校验，于是服务端到客户端的方向还是存在同样的问题，且它也没有做数据包的长度混淆，一样可以通过数据包长度统计分析检测出来。另外此协议并非能抵抗CCA（Chosen ciphertext attack），依然可以通过CCA来确定这是不是OTA协议（通过服务端行为攻击，具体方法这里不说）。
然后再看SSR的auth_sha1和auth_sha1_v2协议，这两协议几乎一样，这两协议都有双向的完整性校验，有数据包的长度混淆，有抵抗重放攻击的能力，但缺点是不能完全抵抗CCA，可使用检测OTA的方法检测出来（不用改动一行代码，但无法区分到底是OTA还是auth_sha1，如要确定，那只要对服务端发向客户端的方向发起CCA攻击即可区分）
再来看看SSR的auth_sha1_v4协议，相对于auth_sha1，在抵抗CCA方面有改进，但依然不是完全抵抗CCA，尽管多增加了长度校验避免服务端行为攻击，但因为校验使用的是CRC32，而CRC32可以通过已知的正确的数据包，再通过同时修改包长度字段和CRC32来伪造出正确的值，所以虽然攻击难度增加了，但并非完全抵抗CCA。不过某防火墙要如此针对性的攻击此协议的可能性非常低，可以认为基本安全，但如果你条件允许，那还是看下面两个协议吧。
最后再看看auth_aes128_md5和auth_aes128_sha1，这两协议在关键的认证数据区使用Encrypt-then-MAC，使其无法CCA，而后续的数据包均使用HMAC，且每个连接的不同数据包用的HMAC的KEY都不一样，之前的攻击方案均失效。对于这个协议我自己还没有想到有效的攻击手段，并且此协议的网络利用率比其它的auth系列协议要高，也是唯一一组抗CCA的协议，所以我推荐大家使用这个协议。不过唯一的缺点是这个协议计算量会比其它的协议要多，代码编写较复杂。关于此协议我写了一个简要的文档说明。
其它花絮：因为auth_aes128_md5协议的前数百个字节不是random的就是HMAC或加密的，总之前面一大堆表面看起来都像是random，所以我曾经试过直接用这个协议裸跑（不使用加密也不使用混淆），结果显示完全能正常使用。但还是不建议大家这么做，毕竟后面还是带着明文的，要是关键字检测会检测到那么后面的话就挂了（但给我的感觉是这个明文关键字检测并不严厉，似乎只针对http, TLS, socks等已知协议）
关于协议就简略讲到这里了（如何攻击这里不讲，否则要列举一堆例子和演示代码，更具体的以后会有机会讲的），有什么问题可补充。
from https://breakwa11.blogspot.ch/2016/11/shadowsocksr.html
---------
ShadowsocksR混淆的选择
最初我设计这个混淆的时候并没有想到如今产生了如此多的黑科技用法，只是想着伪装为看起来像正常的流量，减少被注意到的可能性而已。
对于大多数人来说，混淆并不是必须使用的，不使用混淆其实都能正常使用，而且在这当中有近一半人所在的地区的网络，直接使用原版的SS能获得更好的速度。那么什么时候你应该使用混淆呢？第一类是遇到QoS情况的，使用混淆能提速的人，第二类是所在网络有严格限制，仅能使用80/443端口，不认识的协议根本不能用的（如学校、公司、政府办公网络），第三类是对自己的隐私有要求的，希望在运营商的连接记录里留下看起来正常的访问记录，第四类是试图绕过学校或运营商的计费系统的人，第五类其它黑科技用途保密。以上第四类并不在本文的讨论范围，这属于漏洞利用的非法用途。下文仅针对前三类进行展开。
首先是混淆参数的问题。这个混淆参数可根据你的设定，伪装为对任意host的访问，但我不建议你填写此参数，但建议服务端节点带有域名及正确的解析，这样你不需要填写参数，客户端将直接使用你的节点的域名作为参数。为什么应该这样做呢？因为我了解到，运营商已经在少数地区布置了DNS验证系统（有可能是故意针对SSR的），如果你发出的http/tls请求里的域名解析出的IP地址列表，与你所连接的实际IP不一致，多次请求后就可能会把此IP加入临时黑名单。所以，如果节点有域名，那么参数不写其实是最好的，很多人都习惯写一个大公司网站的域名，其实这反而留下了一个可被检测的地方。
针对第一类人，关于QoS的问题，唯一的办法就是测试了，各地区不同，不同时间效果也不同，不同端口和混淆参数效果也不同。服务端同时开几个端口，一些开http，一些开tls，多测测测出你认为速度较好的组合使用就好。
针对第二类人，那么首先要了解清楚所在的网络环境的限制方式，包括访问端口限制，访问域名限制，协议类型限制，访问IP限制。如果你发现存在访问IP限制，那你可以死心了，除非你在此网络下有另一个节点可以通过它作二级代理访问无IP限制的外部网络。对于端口限制，它限制只能哪些端口，那么你在服务端就开哪些端口，而协议类型除了特别变态的，一般都能用http，如果有域名限制，那么混淆参数就填写能用的域名即可。另外很多公司还有一类外网的访问限制，就是必须通过它提供的二级代理，这时你只需要在客户端的二级代理的地方对应的填写一下即可（部分代理可能必须填写UserAgent）。基本上就是见招拆招，如果有太特别的，没法解决的可联系我说说是什么奇葩的限制（例如不少高校网络都要安装专用的登陆（监控）客户端还只能windows使用，还会劫持你流量的方式才能上网，还限制只能单网卡什么的，那确实非常恶心）。
针对第三类人，如果是联通的比较好办，它提供了可供查询的列表，实验一下你就明白具体效果了。对于其它的运营商，这个列表也绝对是有的，只是不公开给你查询罢了，如果你担心这个，那开启混淆就好了。这种情况下建议使用国内服务器中转并混淆参数使用国内的网站域名。当然，对于这类情况，能更好的减少流量被注意的可能性，即使你所在的网络并没有QoS或其它限制，也能减少被无故限速的风险。
关于混淆就讲到这里了，有什么问题可补充.
对于大多数人来说，混淆并不是必须使用的，不使用混淆其实都能正常使用，而且在这当中有近一半人所在的地区的网络，直接使用原版的SS能获得更好的速度。那么什么时候你应该使用混淆呢？第一类是遇到QoS情况的，使用混淆能提速的人，第二类是所在网络有严格限制，仅能使用80/443端口，不认识的协议根本不能用的（如学校、公司、政府办公网络），第三类是对自己的隐私有要求的，希望在运营商的连接记录里留下看起来正常的访问记录，第四类是试图绕过学校或运营商的计费系统的人，第五类其它黑科技用途保密。以上第四类并不在本文的讨论范围，这属于漏洞利用的非法用途。下文仅针对前三类进行展开。
首先是混淆参数的问题。这个混淆参数可根据你的设定，伪装为对任意host的访问，但我不建议你填写此参数，但建议服务端节点带有域名及正确的解析，这样你不需要填写参数，客户端将直接使用你的节点的域名作为参数。为什么应该这样做呢？因为我了解到，运营商已经在少数地区布置了DNS验证系统（有可能是故意针对SSR的），如果你发出的http/tls请求里的域名解析出的IP地址列表，与你所连接的实际IP不一致，多次请求后就可能会把此IP加入临时黑名单。所以，如果节点有域名，那么参数不写其实是最好的，很多人都习惯写一个大公司网站的域名，其实这反而留下了一个可被检测的地方。
针对第一类人，关于QoS的问题，唯一的办法就是测试了，各地区不同，不同时间效果也不同，不同端口和混淆参数效果也不同。服务端同时开几个端口，一些开http，一些开tls，多测测测出你认为速度较好的组合使用就好。
针对第二类人，那么首先要了解清楚所在的网络环境的限制方式，包括访问端口限制，访问域名限制，协议类型限制，访问IP限制。如果你发现存在访问IP限制，那你可以死心了，除非你在此网络下有另一个节点可以通过它作二级代理访问无IP限制的外部网络。对于端口限制，它限制只能哪些端口，那么你在服务端就开哪些端口，而协议类型除了特别变态的，一般都能用http，如果有域名限制，那么混淆参数就填写能用的域名即可。另外很多公司还有一类外网的访问限制，就是必须通过它提供的二级代理，这时你只需要在客户端的二级代理的地方对应的填写一下即可（部分代理可能必须填写UserAgent）。基本上就是见招拆招，如果有太特别的，没法解决的可联系我说说是什么奇葩的限制（例如不少高校网络都要安装专用的登陆（监控）客户端还只能windows使用，还会劫持你流量的方式才能上网，还限制只能单网卡什么的，那确实非常恶心）。
针对第三类人，如果是联通的比较好办，它提供了可供查询的列表，实验一下你就明白具体效果了。对于其它的运营商，这个列表也绝对是有的，只是不公开给你查询罢了，如果你担心这个，那开启混淆就好了。这种情况下建议使用国内服务器中转并混淆参数使用国内的网站域名。当然，对于这类情况，能更好的减少流量被注意的可能性，即使你所在的网络并没有QoS或其它限制，也能减少被无故限速的风险。
关于混淆就讲到这里了，有什么问题可补充.
from https://breakwa11.blogspot.ch/2016/10/shadowsocksr-obfs.html
No comments:
Post a Comment