上次笔者提到了，很多国外VPN的厂家对自己的产品都安装了混淆的功能，用来绕过（至少是存在于他们的概念中）的『严格互联网审查』

混淆技术多种多样，其中很多都原理都显而易见，比如把OpenVPN的流量包在SSH流量里面，或者直接用类似Stunnel之类的程序，把流量包在TLS隧道里面。但是也有些是较为简单的混淆，比如今天要提到的XOR混淆便是如此。

很黄很暴力的XOR

XOR混淆非常暴力，甚至很多人不愿意称其为『加密』，因为强度实在是太低了，不过，很多情况下确实只需要这么简单的东西。

一个很显然的例子是，SSH的22端口，每天都被人爆破。简单的方法是，把SSH改到高位端口，但是很多情况下也容易被深入一些的脚本小子扫描到端口然后吸引新的火力；更好一些的办法是改密钥登录或者直接安装VPN作为网关，前者确实行之有效，但依然无法避免『被爆破』的可能性，因为SSH程序还在直接监听这个端口，搞不好程序有什么在野漏洞，直接被打爆了，后者对于一些玩具机来说似乎又有些『蝴蝶在花丛中翱翔』的美

此时，XOR就很好了，外部连接先通过XOR反混淆，然后再送到sshd，首先就拦下来一大批脚本小子了（因为他们只能发起标准的SSH连接），即使真的有高级一些的人知道你在用XOR混淆，也得通过主动探测并分析回包的方式来猜测你的密钥。信我，虽然说你的服务器有价值，但是还依然没有这么有价值到值得这么去折腾你的服务器——如果真的这么值钱，那么XOR并不适合你，老老实实用标准VPN可能更好

XOR的局限性

从前面的距离，细心的读者并不难发现的是：XOR混淆并不注重安全性，而是让原来的数据长得不像原来的数据（比如说，OpenVPN过了XOR混淆之后，很多简单一些的DPI软件都无法知道这是啥数据了），其假设底层协议已经做好的必要的安全措施（比如：防重放，防窃听，抗抵赖等等），符合这样标准的下层协议有很多，比如各类VPN协议，TLS，SSH，包括开了TLS的RDP（3389）等等

事实上，如果真要有心人的话，实现不完善的XOR混淆等于没有混淆。这句话是基于XOR本身的特性得出的结论，最明显的例子就是已知明文攻击，知道密文和对应的明文，就可以计算密文 xor 明文，出来的结果就是加密密钥，也就是对应的单字节XOR值

让XOR完善一些

开始说之前，还是得提到一件事：千万不要以为你花两分钟想出来的加密算法，打得过数学家和密码学家几十年的研究

当然，虽然说是打不过的，但是并不妨碍我们在不损失太多性能的情况下，获得比原来的简单XOR稍微强一点的安全性

加长密钥

密码学领域有一个『完美保密性』的概念，简单来说就是，具有该性质的密文不应该透露任何明文的信息，实际实现的做法是让密钥的长度大于等于明文的长度。当然实际操作中其实并不是很符合实际，因为明文可以看作是无限长的，而密钥通常也只是使用固定的一些字符串实现。

现代加密方法对于这个问题的其中一个实现是流加密，也就是使用原始密钥配合伪随机数发生器等方式（记得按一定规律滚动更新种子）产生相对不可预测且足够长的密钥流。其实现关键就在于足够长，比如在给定数据传输速度下，密钥每隔12个小时才会重复一次，那么至少就可以保证这12个小时内传输的数据都具有完美保密性了

IV（初始化向量）

为了让相同的密文和相同的明文在每次加密的时候都可以产生不同的结果，同时也是为了进一步加长密钥起见，程序通常会生成一个固定长度的IV，作为最终密钥的一部分，在加密完成后，会把IV拼接在密文的最前面，以方便解密程序对此进行处理

由于IV是完全可以实现随机的（反正最终也要明文给出去），安全性也会高一些

写在最后

很经典的水文章，但是笔者确实有在写一个XOR混淆程序，其主要作用还是混淆WireGuard流量：笔者抓包发现，WireGuard握手包的特征是非常明显的，基本上就是01 00 00 00开头的一系列流量，长度也是固定的，就可以直接判定为是wg握手包。此外，WG的PSK（预共享密钥）并不能起到混淆的作用，握手包头还是那个握手包头，完全可以实现精准识别

笔者翻了一下Google搜索趋势，是有一部分网友搜索『WireGuard翻墙被封』找到我的博客的，希望这里对此有帮助

（完）