微信接入探秘—加密消息的处理

在上一篇博文中，介绍了被动回调接口的抽象数据层次，并实现了一个高效的实体与xml互转的基础功能。细心的开发者在初次修改公众号的基本配置时会发现一个名为“消息加解密方式”的选项。展开后可供选择的值为：“明文模式”（默认）、“兼容模式”和“安全模式（推荐）”。那么这个安全模式又是什么呢？如何适配安全模式呢？带着这些问题，来进入微信接入的第三次探秘之旅。

可恶的流量劫持在文章的一开始，先给大家看两幅处于正常使用中的手机屏幕截图：

在屏幕的右下角你会看到都有个绿色的水球显示，这与要显示的画面格格不入，很明显不是设计者为之。点开水球，显示的是当前通讯套餐中剩余的流量详情。

从家庭局域网络到Internet再到IDC机房内网，我们的数据链路充满了转发的过程。我们的数据在经过任何一台设备的转发时都有可能被其持久化保存起来。你的办公内网一定安全吗？潜伏在你身边的黑客，通过设置局域网内某个网卡为混杂模式（Promiscuous Mode）可以将局域网中的所有数据都接收一份。可能你并不能发现什么，然而你的私有数据已经被别人窃取。

使用安全模式保护用户隐私

当启用安全模式之后，被动回调接口接收到的消息就产生了很大的变化，形式如下所示：

<xml>
    
    </xml>

可以看出，明文部分保留了该消息的公众号原始ID：gh_38a2de904e09，其余部分均为加密文本（这种结构可以使得同一个后台系统，接入多个公众号，再利用每个公众号的设置进行分别解密）。由于加密结构在官方文档（http://qydev.weixin.qq.com/wiki/index.php?title=加解密库下载与返回码）中并没有明确的阐述，这里就给大家详细地说明一下。

如果读者以前开发过网络协议应该很容易理解这个结构，典型的不定长消息。一定会有一个标识来指明不定长区域的长度，读取时以该值为准，在定长数据之后读取若干字节。在结构的开头，有16字节随机数，该部分数据无实际意义，可用于后续返回加密消息时作为随机数的填充数据。

安全模式的签名验证方法

微信的被动回调接口实际上是一个HTTP POST请求，我们都知道HTTP请求分为请求头和请求体。微信巧妙地将加密的XML数据放在了请求体，将验证签名时使用的参数放入了请求头。

POST /cgi-bin/wxpush? msg_signature=477715d11cdb4164915debcba66cb864d751f3e6×tamp=1409659813&nonce=1372623149 HTTP/1.1
Host: qy.weixin.qq.com
Content-Length: 613
<xml>
    
    </xml>

签名生成的过程：

通过上述计算，现在得出了当前加密消息的签名calculated_sign，然后从请求头中获取参数msg_signature，如果calculated_sign和msg_signature相同，则说明消息没有被篡改过。这种签名策略利用的数学难题有： 
1. SHA1摘要算法对全部数据进行了计算，有任何改动最终的摘要都会发生变化； 
2. Token是事先设置好的，在传输过程中并不包含，无从破解； 
3. 时间戳和随机字符的引入，使得即便明文相同，每一次加密密文都有不同，给破解AES加密增加难度

签名验证成功之后就可以放心地使用解密后的明文了。明文的格式和之前文章中介绍的格式一致，因此解密后的业务处理逻辑可以复用。

作为安全模式的应答，返回的XML格式也应该是加密的，整个加密过程与解密过程方向相反，这里就不再赘述了。

更多微信接入探秘—加密消息的处理相关文章请关注PHP中文网！