ShadowsocksR 协议插件文档

概要

用于方便地产生各种协议接口。实现为在原来的协议外套一层编码和解码接口，不但可以伪装成其它协议流量，还可以把原协议转换为其它协议进行兼容或完善（但目前接口功能还没有写完，目前还在测试完善中），需要服务端与客户端配置相同的协议插件。插件共分为两类，包括混淆插件和协议定义插件。

现有插件介绍

1.混淆插件

此类型的插件用于定义加密后的通信协议，通常用于协议伪装，部分插件能兼容原协议。

plain：表示不混淆，直接使用协议加密后的结果发送数据包

http_simple：并非完全按照http1.1标准实现，仅仅做了一个头部的GET请求和一个简单的回应，之后依然为原协议流。使用这个混淆后，已在部分地区观察到似乎欺骗了QoS的结果。对于这种混淆，它并非为了减少特征，相反的是提供一种强特征，试图欺骗GFW的协议检测。要注意的是应用范围变大以后因特征明显有可能会被封锁。此插件可以兼容原协议(需要在服务端配置为http_simple_compatible)，延迟与原协议几乎无异（在存在QoS的地区甚至可能更快），除了头部数据包外没有冗余数据包，客户端支持自定义参数，参数为http请求的host，例如设置为cloudfront.com伪装为云服务器请求，可以使用逗号分割多个host如a.com,b.net,c.org，这时会随机使用。注意，错误设置此参数可能导致连接被断开甚至IP被封锁，如不清楚如何设置那么请留空。服务端也支持自定义参数，意义为客户端仅能填写的参数列表，以逗号分割。
本插件的高级设置（C#版、python版及ssr-libev版均支持）：本插件可以自定义几乎完整的httpheader，其中前两行的GET和host不能修改，可自定义从第三行开始的内容。例子：baidu.com#User-Agent: abcnAccept: text/htmlnConnection: keep-alive这是填于混淆参数的内容，在#号前面的是上文所说的host，后面即为自定义header，所有的换行使用n表示（写于配置文件时也可直接使用n而不必写成n，换行符亦会转换），如遇到需要使用单独的号，可写为，最末尾不需要写n，程序会自动加入连续的两个换行。

http_post：与http_simple绝大部分相同，区别是使用POST方式发送数据，符合http规范，欺骗性更好，但只有POST请求这种行为容易被统计分析出异常。此插件可以兼容http_simple，同时也可兼容原协议(需要在服务端配置为http_post_compatible)，参数设置等内容参见http_simple，密切注意如果使用自定义httpheader，请务必填写boundary。

random_head（不建议使用）：开始通讯前发送一个几乎为随机的数据包（目前末尾4字节为CRC32，会成为特征，以后会有改进版本），之后为原协议流。目标是让首个数据包根本不存在任何有效信息，让统计学习机制见鬼去吧。此插件可以兼容原协议(需要在服务端配置为random_head_compatible)，比原协议多一次握手导致连接时间会长一些，除了握手过程之后没有冗余数据包，不支持自定义参数。

tls1.2_ticket_auth（强烈推荐）:模拟TLS1.2在客户端有sessionticket的情况下的握手连接。目前为完整模拟实现，经抓包软件测试完美伪装为TLS1.2。因为有ticket所以没有发送证书等复杂步骤，因而防火墙无法根据证书做判断。同时自带一定的抗重放攻击的能力，以及包长度混淆能力。如遇到重放攻击则会在服务端log里搜索到，可以通过grep "replay attack"搜索，可以用此插件发现你所在地区线路有没有针对TLS的干扰。防火墙对TLS比较无能为力，抗封锁能力应该会较其它插件强，但遇到的干扰也可能不少，不过协议本身会检查出任何干扰，遇到干扰便断开连接，避免长时间等待，让客户端或浏览器自行重连。此插件可以兼容原协议(需要在服务端配置为tls1.2_ticket_auth_compatible)，比原协议多一次握手导致连接时间会长一些，使用C#客户端开启自动重连时比其它插件表现更好。客户端支持自定义参数，参数为SNI，即发送host名称的字段，此功能与TOR的meek插件十分相似，例如设置为cloudfront.net伪装为云服务器请求，可以使用逗号分割多个host如a.com,b.net,c.org，这时会随机使用。注意，错误设置此参数可能导致连接被断开甚至IP被封锁，如不清楚如何设置那么请留空。推荐自定义参数设置为cloudflare.com或cloudfront.net。服务端暂不支持自定义参数。

2.协议定义插件

此类型的插件用于定义加密前的协议，通常用于长度混淆及增强安全性和隐蔽性，部分插件能兼容原协议。

origin：表示使用原始SS协议，此配置速度最快效率最高，适用于限制少或审查宽松的环境。否则不建议使用。

verify_deflate（不建议）：对每一个包都进行deflate压缩，数据格式为：包长度(2字节)|压缩数据流|原数据流Adler-32，此格式省略了0x78,0x9C两字节的头部。另外，对于已经压缩过或加密过的数据将难以压缩（可能增加1~20字节），而对于未加密的html文本会有不错的压缩效果。因为压缩及解压缩较占CPU，不建议较多用户同时使用此混淆插件。此插件不能兼容原协议，千万不要添加_compatible的后缀。

verify_sha1（即原版OTA协议，已废弃）：对每一个包都进行SHA-1校验，具体协议描述参阅One Time Auth，握手数据包增加10字节，其它数据包增加12字节。此插件能兼容原协议（需要在服务端配置为verify_sha1_compatible)。

auth_sha1（已废弃）：对首个包进行SHA-1校验，同时会发送由客户端生成的随机客户端id(4byte)、连接id(4byte)、unix时间戳(4byte)，之后的通讯使用Adler-32作为效验码。此插件提供了能抵抗一般的重放攻击的认证，默认同一端口最多支持64个客户端同时使用，可通过修改此值限制客户端数量，使用此插件的服务器与客户机的UTC时间差不能超过1小时，通常只需要客户机校对本地时间并正确设置时区就可以了。此插件与原协议握手延迟相同，能兼容原协议（需要在服务端配置为auth_sha1_compatible)，支持服务端自定义参数，参数为10进制整数，表示最大客户端同时使用数。

auth_sha1_v2（已废弃）：与auth_sha1相似，去除时间验证，以避免部分设备由于时间导致无法连接的问题，增长客户端ID为8字节，使用较大的长度混淆。能兼容原协议（需要在服务端配置为auth_sha1_v2_compatible)，支持服务端自定义参数，参数为10进制整数，表示最大客户端同时使用数。

auth_sha1_v4（不建议）：与auth_sha1对首个包进行SHA-1校验，同时会发送由客户端生成的随机客户端id(4byte)、连接id(4byte)、unix时间戳(4byte)，之后的通讯使用Adler-32作为效验码，对包长度单独校验，以抵抗抓包重放检测，使用较大的长度混淆，使用此插件的服务器与客户机的UTC时间差不能超过24小时，即只需要年份日期正确即可。能兼容原协议（需要在服务端配置为auth_sha1_v4_compatible)，支持服务端自定义参数，参数为10进制整数，表示最大客户端同时使用数。

auth_aes128_md5或auth_aes128_sha1（均推荐）：对首个包的认证部分进行使用Encrypt-then-MAC模式以真正免疫认证包的CCA攻击，预防各种探测和重防攻击，同时此协议支持单端口多用户，具体设置方法参见breakwa11的博客。使用此插件的服务器与客户机的UTC时间差不能超过24小时，即只需要年份日期正确即可，针对UDP部分也有做简单的校验。此插件不能兼容原协议，支持服务端自定义参数，参数为10进制整数，表示最大客户端同时使用数。

auth_chain_a（强烈推荐）：对首个包的认证部分进行使用Encrypt-then-MAC模式以真正免疫认证包的CCA攻击，预防各种探测和重防攻击，数据流自带RC4加密，同时此协议支持单端口多用户，不同用户之间无法解密数据，每次加密密钥均不相同，具体设置方法参见breakwa11的博客。使用此插件的服务器与客户机的UTC时间差不能超过24小时，即只需要年份日期正确即可，针对UDP部分也有加密及长度混淆。使用此插件建议加密使用none。此插件不能兼容原协议，支持服务端自定义参数，参数为10进制整数，表示最大客户端同时使用数，最小值支持直接设置为1，此插件能实时响应实际的客户端数量（你的客户端至少有一个连接没有断开才能保证你占用了一个客户端数，否则设置为1时其它客户端一连接别的就一定连不上）。

推荐使用auth_chain_a插件，在以上插件里混淆能力较高，而抗检测能力最高，即使多人使用也难以识别封锁。同时如果要发布公开代理，以上auth插件均可严格限制使用客户端数（要注意的是若为auth_sha1_v4_compatible，那么用户只要使用原协议就没有限制效果），而auth_chain_a协议的限制最为精确。

混淆特性

说明：

• 20%/100%表示首包为20%，其余为100%速度（或带宽），其它的RTT大于0的混淆，前面的表示在