atgateway内置协议流程优化-加密、算法协商和ECDH
Last updated
Was this helpful?
Last updated
Was this helpful?
之前就有计划优化游戏服务器框架网关层的内部协议了，这次泰国旅游回来，新公司入职前，正海有空来做这件事。
以前提到过，最初决定重构这个流程是因为我觉得之前的方法，如果以后要扩展新的算法的话非常的麻烦。而后我看了一下shadowsocksr对多种加解密算法的实现方法，觉得还不错。就打算用类似的方法重写一下。当然也是因为写第一版的时候没考虑太多关于加解密方面的细节，还是优先实现出工程上可用的东西。这次就先稍微深入看了下像和的一些实现，特别是下面会提到的cipher的实现。并以这个为基础来实现以后可能的增加加密算法的扩展。
新的加密算法的适配目标是改成通过字符串来指定可接受或者可用的加密算法（比如：XXTEA:AES-256-CFB:AES-128-CFB）。我思考了一下，似乎是没法向前兼容地实现新的协议流程，所以既然向前不兼容，那么干脆协商这边也可以优化一下。
原先是服务器和客户端自己配的加密算法ID和密钥长度，然后握手阶段校验两边的算法和密钥长度是否一致。现在就改为服务器先配置接受的加密算法，客户端发起握手的时候提交可用的加密算法集合。然后由服务器选定具体用什么算法。重连的时候就只能传上一次的密钥和加密算法了，当然重连成功后任然会触发一次密钥更新。
当然我也考虑并看了一下是否直接使用SSL，但是一方面并不是特别需要类似CA校验这种流程，而且直接使用SSL还有一些额外开销，并且还不太好评估有多大。另一方面这个替换改造起来会更复杂的多，所以至少这个v1的inner协议是不会使用SSL了，可能有需要后面专门写一个SSL的模块。
另外协商流程没有变化，还是不加密、直接发送密钥和DH密钥交换，当然还多预留了一个ECDH。这部分的基础设施还没像加密算法那样在基础库里做比较好的抽象和适配，所以目前暂时不做变化。（我怎么觉得要是都改了相当于我自己手写了个SSL流程？）
有一个额外增加的协商的部分是初始向量（iv）。之前的AES的加密的初始向量写死的是全0值，这次也通过协商算法搞出来了。
原先的流程在DH算出密钥之后，会那一段随机出来的数据测试两边是否一致。
具体来说就是，服务器向客户端发送一段数据，客户端加点尾巴，在发回来。服务器校验前缀。但是这个流程是有问题的，因为后来了解到，加密算法的加密是按block来的，如果对齐的话，后缀数据并不影响前缀的加密结果。所以会原样发回，这样校验也就失去了意义。
那么现在改成客户端把服务端发来的数据的奇数字节重置掉发回去。这样两边的数据就不一致了，然后服务器校验偶数字节即可。
当然也可以对密钥hash然会发回校验，不过这个也需要等后续有时间我可以对Hash算法也做类似cipher的基础组件之后。当然和都有类似的设施，但是我不想直接用，还是想可以加入自定的Hash算法，因为这里并不特别在意减少碰撞，所以不需要md5或者sha1那种长度。当然考虑到以后改造要向前兼容的话，只要加一个字段。如果是默认值，走现在的校验流程，否则，走某种Hash校验算法即可。
另外，虽然加密算法库都有提供cipher，但是他们的字符串名称是不一样的，所以这里也要适配一下（就这个地方和shadowsocksr类似）。
我们全部用上面的名称，也就是openssl里的名称，其他库里做别名映射。
这里面我同时封装了加密端（ciphercontext.enc）和解密端（ciphercontext.dec），所以有两个。
不过哪天接入的自定义算法多了我就和这个库的cipher的写法一样，改成回调函数的函数组的形式。其实相当于手写面向对象的虚表啦。
其实再以后再有空还可以试试适配Apple内置的加密库。不过如果只是cipher还好，然而还要另外接DH之类，还是有点麻烦。所以也往后放放吧。
除了前面提到的关于协商方式和校验密钥的可以改进之处以外，有空的话感觉还是应该写下单元测试。虽然这个单元测试很麻烦而且得先抽离服务端的接口。或者改成一个单元测试的脚本也许也可以，具体还没想好。不然像现在跨平台测试+跨库测试，真是很是折腾人。
这一次是人工都测好了，并且已经合入master分支，但是自测过程非常麻烦。实在不想再次折腾，不过得等有空再说吧。优先还是实现ECDH。
不过协议安全的考量上似乎还有点小问题。假设第三方劫持了网关，让网关同时当服务器和客户端，并解码转发数据，似乎还是可以获取原始内容。这种方法和现在一些路由器上破解HTTPS的方法如出一辙。这种也有一种防御方法，就是加一层RSA，然后客户端保存public key的hash码。客户端收到公钥后要校验HASH码。好像饿了么客户端就是这么做的。不过这也挡不了万一人家再改你的包，而且这样公钥就不能更新了，玩意泄露了就GG了。所以暂时我也没做这一层。也许后面有什么更好的方法可以解决这个问题。
前面有说，之后新算法的适配就靠这个Cipher了。其实也是以前不知道，、或者其他假面算法库基本都有写这个加冕算法流程的抽象。以前我们都是自己写，也是因为我们一种业务也不需要太多种加密算法。其实同时他们也有类似地对Hash也有类似的抽象的设施，称为MD，然后因为要支持类似HTTPS里那种TLS或者SSL的交换流程，所以对密钥交换（DH、RSA、ECDH）也有类似的设施。当然他们还有更多得验证啊之类的流程，比较复杂。
所以有了这层抽象以后，我就不需要单独针对每一种加密算法自己做适配了。只要适配cipher即可。同时再加入一些我们自己定义的额外的加密算法，比如。
XXTEA算法在里有提供，但是里没有。这个算法很简单而且相当高效，虽然安全性稍差些。但是在游戏服务器里，我们会定期换密钥，可以抹平这个安全性稍差带来的风险。所以里一直内置支持。不过这次适配cipher之后，这个算法流程就有点小变化。现在这个版本额外加入的自定义算法只有所以我就直接switch实现了，像这样：
其实我是比较想加入这个的算法的，据说新能4倍于AES，特别是移动设备上性能特别好。但是我还不清楚他的实现细节，所以没有擅自作为自定义算法加进来。而且以后新版本的加密算法库都会陆续支持起来，比如的1.1.0以上的版本。所以我就依赖cipher做适配了。在2016年就有人打过一个patch是增加chacha20算法的。不过官方现在都还没review并放进来。
跨平台和跨库还是用之前的方法。前面都贴了代码了，这里就不贴了。唯一就是碰到一个坑，因为我豆子自己处理的文件读取，然后读出来的Buffer传给或者库。是正常的，但是的mbedtls_dhm_parse_dhm接口要求传入的数据的最后一个是0。结果我还得给它补个0。也是醉醉的。
重新适配的问题倒是不大，就确定了一下文件名，然后协议的更新和接口，移除keybits之类，然后加了个可以获取所有支持的加密算法的接口。
也叫椭圆双曲线密钥交换，仍然是使用DH算法做密钥交换，但是用[ECC椭圆曲线的离散对数][9]替换掉DH Paramater。据说是在同等安全性的情况下大幅减少密钥长度，所以消耗也会大幅降低。这个只是协议上做了预留，还没接，因为按之前接DH的尿性，又是得去看下和的源码和test才能知道标准的流程。会稍微麻烦点。不过因为它和DH的流程是差不多的，所以接起来应该不会很困难。
[9]: