Thursday, November 3, 2016

ShadowsocksR协议的选择

其实这个要说的少得多,总之就一句话,能用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等已知协议)

关于协议就简略讲到这里了(如何攻击这里不讲,否则要列举一堆例子和演示代码,更具体的以后会有机会讲的),有什么问题可补充。

6 comments:

  1. This comment has been removed by the author.

    ReplyDelete
  2. 我就在用auth_aes128_md5,不过开了兼容

    ReplyDelete
  3. 一直以来都想对breakwa11金钱上的支持,但是breakwa11拒绝,那至少想对breakwa11语言上的支持:你的工作使无数人受益匪浅,我对代码理解不多,但是我也会尽力推广让更多人受益于技术。

    ReplyDelete
  4. ipv6 to ipv4 应该选择什么?

    ReplyDelete
  5. 请问auth_xxx_compatible类的协议插件支持参数不?

    ReplyDelete
  6. 真的是个妹子吗?教我编程吧(认真脸)

    ReplyDelete