某些翻墙工具的安全性

虽然网络上充斥着对某些上网工具不同参数组合的主观感受和近乎玄学的经历，以及种种工具间粉丝的互撕，但奇怪的是我却很少看到有人真正分享安全性背后的原理和不安全的原因，种种描述和感受常常让人有一种火电水电的既视感。
虽然我对于 Cryptography 只是略懂皮毛，但是还是想写点分析，算是抛砖引玉了。写的比较浅显，毕竟啥也不精，也没能力做学术交流，如果有什么意见可以随意留言。预备知识只需要一点点对称加密的皮毛即可。
Updated:
感谢Riobard的讨论，增加了一些安全本身的分析。

在我们谈安全时，我们究竟在谈什么

查了一下清华计算机系培养计划，居然没有一门针对安全的，可能是我漏了。又查了一下浙大，唯一一门但还是选修课……
我个人是觉得呢，其实与其开那些花里胡哨的“人工智能”相关课程蜻蜓点水，或者搞得和个培训机构一样搞什么 Android、 iOS 开发，还不如好好教上一些基础，出来也算是无负于科班的名声。毕竟如果一个刚培训出来上岗俩月的就算了，零基础速成，要求安全未免太过。如果科班出身也弄出什么密码明文存储， hash 两遍增加密码安全性或者多种 hash 结合增加破解难度这些常见的“安全手段”的话，实在是说不过去吧。
不过话说回来，大多数安全问题的主要原因，并不是安全意识的好坏，而往往是 code by accident¹ 的结果，用心不用心，负责不负责才是很多网站出安全问题的根本原因。
不废话了，言归正传，扯这么多无关的只是想说，安全这个东西吧，根本没人重视，很多时候很多人根本就不知道，也懒得搞明白自己在说什么。别的东西你随便找个网站复制黏贴它碰巧work了你就交差，看个demo恨不能直接解决你的问题（所以你活该要加班修 bug ），忽悠过去了就跑去和人家说你是“掌握”、“精通”，具有多年工作“经验”。但是一旦涉及安全问题，只要你没明白背后的原理，99.99% 你的理解是会出现偏差的。 ss 安全性的妖魔化就是例证。
通常的 Cryptography 有很多方面，而我们关心的工具我想应该只关注以下方面：

1. Confidentiality
2. Integrity
3. Authentication

另外还有一项无关 Cryptography 的问题， Obfuscation。
除此之外的一切，要么是无关安全的实现细节，要么是更为艰涩的玄学，我就留待大神去分析了。

协议

在展开任何细节之前，我们先看看基本的协议是怎样的。
ss 最基本的协议非常简单，从它的名字也可以看出来，是一个简化版的 socks 代理协议。

IV: VARIABLE | TYPE: 1 BYTE | REQUEST: VARIABLE

其中，从 TYPE 开始的内容均为加密的，而 REQUEST 的内容根据 TYPE 的不同而不同。 Initial vector 应该不需要解释了吧。

TYPE = 1

请求连接到 IPv4 地址：

IP: 4 BYTES | PORT: 2 BYTES | FORWARD DATA

TYPE = 4

请求连接到 IPv6 地址：

IP: 16 BYTES | PORT: 2 BYTES | FORWARD DATA

TYPE = 3

请求连接到域名：

HOST_LEN: 2 BYTES | HOST: HOST_LEN BYTES | PORT: 2 BYTES | FORWARD DATA

在服务器回复的时候，直接回复 IV 和加密后的数据，而所有的加密方式都是对称加密。

加密算法

在读下去之前，我先问大家几个问题，大家可以自行判断你觉得如果一个算法的加密强度能够达到以下层级对你究竟是安全还是不安全，注意，只是解密你的数据，不是破解算法达到秒解数据需要的时间：

1. 加密数据即便使用最顶级的超级计算机也需要一千年才能解密
2. 加密数据使用最顶级的计算机需要3个月才能解密
3. 加密数据使用普通台式机3个月就可以解密

大体上来说，现在大家闻之色变的算法处在若干年后基本也进入不了2的状态，很多大家表示最好换掉的处在1往上的状态，3的算法基本没有用过，因为新算法的运算量往往是几何级数增长的。
既然解密不可行，那么有没有其他的安全问题呢。
我先分析一个真实案例，大家可以判断这是安全呢还是不安全。
假设一个算法，一个中间人必须要记录你的所有数据连接传输的数据，如果他人品爆发，可能几百万条连接，如果正常，可能是几万亿条连接之后，他可以得到其中某两条（不可选择）的数据的明文异或后的值。
注意条件，这个中间人，可以取得你传输的数据，并且把它记录下来，然后还要进行匹配，费尽千辛万苦，在人品大爆发的前提下，才有可能获得数百万不止的连接中随机两条的数据明文的异或值，基本上连这两条数据是什么都恢复不出来，这还是在他确定你用了这个加密算法的情况下。
这个算法安全吗？
这差不多就是 ss 加密的安全程度，甚至还要安全数万倍不止。
在学界和业界的一些人看来，这个算法是不够安全的，不错，但是对你安全不安全，我觉得大家可以自己判断。
好了，废话扯完回归协议本身。

问题在哪？

这个似乎已经“不安全”成一个筛子的协议的问题究竟出在哪呢？
如果有安全意识的应该已经感到这里有一点问题了，在一个加密流中，泄露某一位的真实值其实很可能不安全。
在 ss 协议中，IV 几乎是定长的，而数据明文第一位的值为 1，3，4，必居其一。
由于加密前后的数据是等长的，显然，对应位的密文的 256 种情况必然一一对应明文的 256 种情况，换言之，保持 IV 不变，尝试 256 次就必然可以得到一次服务器认为 TYPE 是 1 和 4 的情况，在TYPE 是 1 和 4 时，服务器会尝试连接由后面的数据所给定的 IP 地址和端口，而任意的 6 或 18 Bytes 都构成了合法的请求。
在服务器收到不合法的请求的时候（TYPE 不是 1，3，4）会直接断开，而接到之前提到的请求的时候会去尝试连接目标地址，这样只要保持 IV 不变，随机生成 18 Bytes 数据，第一位尝试 256 种可能（其他位完全无所谓）即可根据服务器的行为进行判断这是不是 ss 服务器了。
问题出在哪里呢？就出在 ss 的实现上，立刻断开和过一会断开的行为差异。
其实这个问题非常好解决，有两种办法：
第一个是：只要保证 ss 的行为对于合法和不合法请求没有差异即可。
在服务器接受到一个合法的伪造请求连接至随机的远程服务器时，有几种可能：

1. 连接成功。对于一个随机的地址和端口来说，非常不可能，可以忽略。
2. RST。
3. 超时。这是最有可能的情况。

对于第二种，服务器会很快断开到客户端的连接，对于第三种，则会等的更久一些。
所以其实解决方案很简单，在发现请求非法时不要立刻断开，而是随机等待数秒后再进行断开即可。
第二个方法其实更简单也更根本，不使用 TYPE 1 和 4，这样只要验证一下 HOST 是不是合法的域名就可以了，而随机生成合法域名是非常困难的（并不是每一个ASCII都构成合法域名，何况你的 HOST_LEN 也要合法）。只要规定 HOST_LEN 和 HOST 必然由一个 IP 包发来，事实上这也是几乎所有实现出于简化的假设，即可。
如果采用重放，二依然可能会有一点点问题，如果担心这种可能性存在，还是可以采用一。

所以它已经解决了？

这两个简单的解决方案至今也没有被实现，反而有一种用新的问题来掩盖久问题的趋势出现。所以，这个问题还没有彻底解决，大家还可以继续撕一会儿。
回到最开始我们提到的安全性三个方面，Confidentiality 之前已经说了情况了，到底有没有问题大家自行考量， Integrity 可以说在设计之初就并没有列入考量（这并没有问题，我懒得展开了，但是篡改数据没有任何意义，感兴趣的同学可以查看这里的说明²）， Authentication 其实是通过 TYPE 来实现的，也是出问题的地方所在，但是即便如此，伪造的请求就和 hash 的碰撞一样，都是合法的随机样本，没有实际意义。
虽然简单混淆 Authentication 成功和失败的行为或者增加欺骗 Authentication 的成本即可解决问题，但是很显然这场大戏并不想就此停息，所以各方的算法层出不穷。我没有精力分析这些算法从 Integrity 和 Authentication 的角度是如何解决这个不存在的问题以及在此同时可能引入新的问题的，况且这并不是当前需要解决问题的关键所在。

另一个问题

IPv4 的地址有 $2^32$ 个，每个 IP 的端口有 $2^16$ 个，那么如果有人想要进行探测，他怎么知道要探测哪里去呢？显然不能是随机的，这就牵涉到一个问题， Obfuscation。
设想一下，你的电脑对一个服务器的某一非常见高端口进行大量主动链接，传输大量随机数据。
又或者，你的电脑连接至80或443或25端口，但传输显然不是 http， https 或是 smtp 的数据。
那么，作为通路中的一个时刻都在分析数据的节点，同学，这特征真的已经显著的不能再显著了好么。
特别是考虑到经常有很多不同的设备连接到这个服务器发送大量随机数据的情况，想不注意到你真的好难。
怎么办呢？
我们需要 Obfuscation， 将数据流伪装成另一种数据流（这并没有在理论上增加安全性）。
具体实现已经有了，虽然 ss 中似乎来来去去，我也搞不清楚情况，但在 ssr 中，如 http_simple 和 tls1.2_ticket_auth 等等通过在头部伪装成普通的 http 或 https 在一定程度上规避了这个问题。同时，在某些网络下可能还能通过欺骗 QoS 提升速度，不过这和本文无关了。

That’s all?

Emmm…
其实特征并不只有请求的头部（http 头， SSL 握手），中间的每一个数据包的长度都可能在暗示着当前传输的内容。不过考虑到这所需要的运算资源和准确度，我实在不觉得有必要在意太多。要明白，行为本身的特征已经相当明显，而所有其他的流量混淆都必然增加 overhead，在我看来完全是得不偿失。

总结

所以，ss 加密的问题我基本都已经写出来了，够不够安全大家可以自行判断；服务器有可能被探测，只要在实现上略作修改即可，但是似乎大家比较喜欢从理论上解决无人想去修正（虽然漏洞本身只是实现上的）。
至于， Obfuscation，如果 QoS 很有效可以考虑使用，其他时候也可以求个心理安慰吧。
写这篇文章的主要原因，并不是想要否定任何想要取得更高安全性的努力，只是想让讨论本身回复一个理性的状态。如果想说 ss “不安全”，至少先把究竟多不安全说清楚吧。

1. https://trevan.co/dont-code-by-accident/
   
2. https://github.com/shadowsocks/shadowsocks-org/issues/64
   
   from https://blog.zhuhaow.me/security/ss/2017/04/07/the-security-myth-of-some-network-tools/
   
   ----------------------
   

   各种加密代理协议的简单对比

   目前我们常用的加密代理有协议有 HTTPS，SOCKS5-TLS 和 shadowsocks,此文从各个角度简单分析各个协议的优劣，以帮助各位选择合适的协议。
   先简单说些背景知识，以上协议都是基于 TCP 的代理协议，代理协议（Proxy Procotol）与 VPN 不同，仅可被用于通过代理服务器转发 TCP 连接（shadowsocks 支持代理 UDP），而 VPN 可被用于 IP 层上的所有协议，如 TCP、UDP、ICMP 等。所以在使用代理时，ping 等 ICMP 应用是不可以被代理的。
   然后简单解释一下什么是 TLS，TLS 又名 SSL，是针对数据流的安全传输协议。简单来说，一个 TCP 链接，把其中原本要传输的数据，按照 TLS 协议去进行加密传输，那么即可保证其中传输的数据安全。这个安全至少体现在以下几个方面：
3. 数据被加密，任何可以截取到 TCP 数据流的人，无法解密出原始数据；
4. 数据不可被篡改，一旦篡改会导致解密失败，连接断开；
5. 服务器身份验证，基于 X509 的证书体系去确认目标服务器是否为真实的服务器。

明文的 HTTP 套上一层 TLS，也就变成了 HTTPS，SOCKS5 套上 TLS，就变成了 SOCKS5-TLS。TLS 协议是整个互联网安全的基石，几乎所有需要安全传输的地方都使用了 TLS，如银行、政府等等。

当被用作代理协议时，HTTP 层和 SOCKS5 层去进行具体的代理连接控制，如进行身份验证、告知需要转发的目标主机名等。所以不需要 TLS 他们也可以用作代理，只不过所有数据都是明文传输，不具备安全性。加上 TLS 后，由 TLS 去保证安全。而 shadowsocks 协议则融合了代理控制和安全保证。所以后文的很多对比实际上是 shadowsocks 和 TLS 的对比。

性能

TLS 协议由于承担了一项额外的功能，需要验证目标服务器身份，导致其握手时会比较复杂。

ping 的时间表示，一个 IP 层数据包从本地发出，到服务器再返回的来回时间，即 RTT（round-trip time）。

在发起代理连接时，首先我们需要进行 TCP 3 次握手，耗时为 1 个 RTT。（此处把最后的 ACK 直接并入后续的数据传输部分）。

然后进行 TLS 握手，因为服务端和客户端需要进行身份验证并协商协议版本号、加密方式等细节，第一次连接时需要 2 个 RTT。当然 TLS 的制定者也发现这太慢了，于是引入了 TLS Session Resumption，当服务端和客户端服务器连接过一次后，之后的连接可以直接复用先前的协商结果，使得 RTT 降低到 1 个 RTT。但这需要服务器和客户端的支持。（这是为什么 Surge benchmark 时，对于 TLS 代理第一次的测试结果可能较慢的原因之一）

对于 HTTPS 协议，当 TLS 连接建立后，客户端通过 HTTP 层发起代理请求，服务端回应连接建立，此后进入正常的代理通讯环节，再耗费 1 个 RTT。

对于 SOCKS5-TLS 协议，当 TLS 连接建立后，如果没有验证的环节，那么需要再耗费 1 个 RTT，如果有验证（用户名密码），那么需要耗费 2 个 RTT。

而对于 shadowsocks，由于使用的是预共享密钥（pre-shared key, PSK），加密方式也是预先约定好的，所以不需要进行协商，只需要在 TCP 建立之后，再耗费一个 1 个 RTT 告知目标主机名。

总结如下：

HTTPS（TLS Session Resumption）：3 个 RTT

SOCKS5-TLS 无验证：3 个 RTT

SOCKS5-TLS 有验证：4 个 RTT

shadowsocks：2 个 RTT

（注：最后一个 RTT 并不严谨，因为客户端可以在最后一个 RTT 产生响应前，直接开始后续传输。另外如果使用了 TCP Fast Open，可以看作 TCP 阶段 RTT 为 0。）

对于日常使用，最影响性能的就是握手速度，后续传输过程中的加解密性能，对于现代 CPU 来说基本都不会构成瓶颈。 shadowsocks 由于有 PSK 的特点，在 TCP 协议基础上已经达到极限，不可能有协议能再低于 2 个 RTT。

所以，同等网络环境下，shadowsocks 是明显快于 HTTPS 的。（体现在延迟上，而不是带宽）

另外，最新的 TLS 1.3 协议正力图解决这个问题，由于目前还处于草案阶段，各种工具链不完善，现在不太好评估实际效果。

数据安全性

（此处说的数据安全性，指的是加密后的流量是否会被截取并破解的问题。）

对于 TLS，作为个人用户，丝毫不用担心，TLS 协议如果真的不安全了，世界早就乱套了…

对于 shadowsocks，使用的加密方法也都是工业上成熟的算法，从数据安全性角度考虑也基本不用担心。

抗识别

这个问题有两个角度需要考虑：

1. 观察一段数据流量，是否能判别这是一个代理协议的流量；
2. 对于一个仅暴露出 TCP 端口的黑箱，能否判断这个端口提供了代理服务。

对于 shadowsocks 协议，在第一点上，观察者只能判定这个数据流为未知的协议。而第二点，shadowsocks 的几次修改，都是因为在这出了问题，目前最新的 AEAD 加密方式，应该已经解决了这个问题，但还需要时间去检验。

对于 HTTPS 协议，在第一点上，观察者是无法去区分这是一个代理还是一个标准的 HTTPS 网页访问的。而第二点，在妥善配置的情况下，也是完全无法判别。

但在实践中，大部分 HTTPS 代理服务器为了兼容浏览器行为，在直接被当做 HTTPS Web 服务器访问时，会返回代理错误页或者 407 Proxy authentication required，直接暴露了自己是一个代理，如果要抗击第二点，可以将服务端的行为修改为，如果请求的 Header 中，不包含一个有效的 Auth，那么就返回一个标准的 200 页面，这样从理论上杜绝了被嗅探的可能。

总结一下，最新的 shadowsocks 已经能满足抗识别的两个要求，但是观察者得到结论是“未知协议”。而使用 HTTPS，观察者无法判断这是一个 HTTPS 代理还是 HTTPS Web 服务器，这是更优的结果。

Hiding true identities inside a seemingly ordinary. — Person of Interest S03E23

部署难度

HTTPS 协议使用广泛，有众多成熟的工业级工具，如 squid，haproxy，nghttp2 等等，但是由于 HTTPS 协议本身比较复杂，配置起来参数众多，有很多性能相关参数需要自己调优，所以一般用户配置起来会有难度。

shadowsocks 经过多年发展，目前也已经有众多的软件支持，但是对于不同特性的支持度不一。由于参数简单，部署配置起来极其方便。

功能

shadowsocks 目前还存在一些功能上的缺陷：

1. shadowsocks 没有设计错误回报机制，对于以下错误，客户端看到的行为都是服务器主动断开 TCP 连接：

• 密钥或者加密方法错误
• 目标主机名 DNS 解析失败
• 目标主机不可达
• 目标主机拒绝连接

这使得客户端没办法根据不同的错误采取进一步的动作，只能简单的向用户返回 Socket closed by remote 错误。

2. shadowsocks 没有考虑用户鉴别，使得服务端 ACL 或者流量统计等功能无法实现，主流的 workaround 是通过不同的端口号去识别不同的用户，但这极其浪费资源且很不优雅。

3. 部分 ISP 对于非 HTTP 和 TLS 的未知流量，会进行降速限制，这个可以通过配置 obfs 解决.

from https://medium.com/@Blankwonder/%E5%90%84%E7%A7%8D%E5%8A%A0%E5%AF%86%E4%BB%A3%E7%90%86%E5%8D%8F%E8%AE%AE%E7%9A%84%E7%AE%80%E5%8D%95%E5%AF%B9%E6%AF%94-1ed52bf7a803
---------------------------

实际上讨论的范围不仅限于 Shadowsocks，但不可否认它是目前最流行的翻墙工具，所以也是最大的目标。当然了，这类的讨论不会有什么明确的结论，谁都说服不了谁。重要的是大家表达了自己的观点和需求，让旁人也能更好的了解翻墙中可能碰到的各种问题。
于是我也来凑个热闹，说说 V2Ray 的设计理念。
首先，V2Ray 是什么？V2Ray 是一个网络代理工具。什么是代理？代理是当 A 和 B 想说话但不能直接对话时，要找 C 来传话，这时 C 就是代理。那么在这个过程中，C 有哪些职责？很简单，把话传到，把话传对，并且不泄露给除 A、B 之外的人。
看似这个描述很简单，把它应用到代理软件中，可以表述为下面的内容：

• 开放网络连接，使得 A 和 B 可以间接地进行正常通信；
• 通信内容不能被第三方知晓；
• 网络连接要稳定，不能间歇或永久地失效；

之所以没有写成一二三条，是因为上述三条的优先级，在不同的人看来是不一样的。
大多数人的选择应该会是“正常通信”。毕竟翻墙工具诞生的意义就是让用户访问被墙的网站，比如 Google 被墙了，我架设一个 Shadowsocks 服务器就又可以访问 Google 。至于我在 Google 上搜索了什么，都是一些人畜无害的内容，我想别人也没兴趣知道。只要这个工具能让我爽快地访问 Google，它就是一个好工具。这种情况我们称为“速度优先”。
另外一些人可能就比较注重私密性，不管我在搜索一些什么内容，可能也就是一些网红八卦，但我就是不想让别人知道，被别人知道了我就不爽。这种情况我们称为“隐私优先”。
还有一些人对服务器的稳定性有需求，平时我不怎么翻墙，而一旦需要的时候，就一定要可以及时翻出去。几百万的大单，谈不成这个月就要喝西北风了。这些人对翻墙服务（或服务器）的稳定性要求很高，服务不能断线。而断线的情况有很多种，比如翻墙协议被识别了，或者服务器被探测了，都可以造成翻墙服务失效。这种情况我们称为“稳定优先”。
上述的三种情况在翻墙工具中都有相应的功能，比如“速度优先”可能的问题是 ISP 的 QoS 限制，应对方式是流量混淆。又比如“隐私优先”可能需要工具提供完美的加密方式。而“稳定优先”需要翻墙服务器不被探测，翻墙协议需要减少特征。正是由于这些纷繁复杂的功能，引起了大量的讨论。观众不明就里，而开发人员则忙于推销自己的产品。有些问题呢，就越讨论越看不懂了。
从 V2Ray 的角度来看，这是一个不可调和的矛盾。每个人的需求不同，适合自己的才是最好的。不能因为开发人员觉得一项功能好，就强加给用户。用户用着没效果，也不会感谢开发者。
举个例子，Shadowsocks 最近的一次协议升级，使用 AEAD 算法取代了 OTA，提供了更好的加密特性。这个升级在“速度优先”的用户看来是完全没有意义的。因为 AEAD 只是加强了数据完整性，对于 QoS 和可被探测性没有任何改进。也就是说，在客观环境不变的情况下，升级到 AEAD 不会在翻墙速度上有任何提升。于是很多人就会问，到底要不要升级 AEAD，升完对我有什么好处。由于惰性，在没有明显优势的情况下，AEAD 的推广有着很大的阻力。
V2Ray 则尝试从另一个角度来解决这样的问题：提供很多功能，让用户根据自己的需求自由组合。虽然各种组合并不一定能满足所有人的需求，但总比只有一个选择来得好。
对于上述的三个需求，V2Ray 分别提供了不同的特性：

• 速度优先：VMess 协议、mKCP 协议、Mux.Cool 协议，内部路由分流
• 隐私优先：TLS (完整实现，非伪装)
• 稳定优先：HTTP 伪装、BT 伪装等，以及 Mux.Cool 协议。

V2Ray 在设计时已考虑到多个功能相互组合的使用，比如你可以使用 VMess + TLS 来达到隐私和速度的双重保证，或者使用 VMess + Mux 来提升速度和稳定性。也考虑到不同的用户的需求不同，V2Ray 的所有功能都可以选择打开或关闭，不会把任何一个功能强加给用户。不同的配置可以达到不同的效果，而在 V2Ray 中，你只需要一个配置文件就可以应对这些不同的需求。
当然 V2Ray 的功能远不止上述这些，如果你现在的翻墙工具已不能满足你的日常需求，何不试一下新的轮子呢？

from https://www.v2ray.com/blog/2017/design.html
-------------------------------

翻墙协议的三要素

 这次我们来讨论一下从工程的角度如何理解翻墙协议，每个翻墙协议有什么差别。

首先，我们来设定一个概念：一个代理（翻墙）协议可能具备的三要素。
一、传输：能在 A、B 两个主机之间建立一条安全可靠的通信通道，用于传输数据； 二、协议：对于将要传输的数据，能将这些数据的目的地告知代理服务器； 三、内容：可以对传输的数据进行优化，比如压缩、合并等。
任何一个翻墙协议都具备以上三要素中的几个或全部。
文字可能较难理解，我们来举一个简单的例子：Socks 协议。Socks 只具备协议要素，即告知代理服务器要把数据发送到哪里去，以达到代理的目的。但众所周知单纯的 Socks 不具备翻墙能力，因为它不能建立可靠的通道（即会被墙）。于是就有了 Shadowsocks。Shadowsocks 在 Socks 的基础上增加了传输要素，对数据加了密，使墙无法分析其内容。而 Shadowsocks 不具备内容要素，因为对于客户端的发来的内容，Shadowsocks 不进行任何修改，直接发送给了代理服务器。
在翻墙过程中，我们可能会使用几个协议的组合，比如 Shadowsocks + KcpTun。无论我们怎么组合，所产生的结果，必须包含传输要素和协议要素，才可以进行可靠的翻墙。
为什么不能单独使用 KcpTun 来翻墙，因为 KcpTun 只有传输+内容要素。KcpTun 只能建立连接，对内容进行一定的处理，比如加密以及其内置的 mux 模式。但它不能发送数据的实际目的地，导致了一定要再套一个其它协议才可以用于翻墙。
而在 Shadowsocks (传输+协议) + KcpTun (传输+内容) 的场景中，由于两者都有传输要素，重复了，以至于 Shadowsocks 的加密在这个场景中多余。因为 KcpTun 已经有加密了，Shadowsocks 再多加一层也没用。
这也就是 ShadowsocksR 最近的几个协议推荐使用不加密的原因。
ShadowsocksR 本质上是对 Shadowsocks 进行了一层封装，即 Shadowsocks + X。这个 X 包含了对协议要素的扩（单端口多用户多种加密方式），加强了传输要素（伪装和其它的加密方式）。和 Shadowsocks + KcpTun 同理，Shadowsocks 本身的传输要素就显得不那么重要了。
而 Shadowsocks 最近也加强了传输要素，即 obfs plugin。两者在要素这一层面相差无几，这也是为什么很多人不认为 ShadowsocksR 之于 Shadowsocks 有很大改进的原因。
顺便整理一下常用协议所具备的要素，仅供参考：

• HTTP/1.1: 协议
• HTTP/2 (不带 TLS): 协议+内容
• TLS: 传输
• Shadowsocks: 传输+协议。AEAD 只是强化了传输，并没有添加新的要素。
• ShadowsocksR: 传输+协议
• KcpTun: 传输+内容
• GoProxy: 等价于 HTTP/2 + TLS，即传输+协议+内容
• VMess (V2Ray): 传输+协议
• mKCP (V2Ray): 传输
• WebSocket (V2Ray): 传输
• Mux (V2Ray): 协议+内容

当然，一个翻墙协议的效率和它具备几个要素没有半点关系。以上这些内容只是帮助大家理解每个翻墙协议的侧重点，哪些组合是有意义的，哪些是没有意义的。一个协议组合首先要有意义，其次才能探讨它的效率.

from https://www.v2ray.com/blog/2017/layers.html