各位微信开发者： 以下是上周小程序相关能力更新及我们在社区收到的问题反馈、需求的处理进度，希望同大家一同打造小程序生态。 小程序“更多类目”功能上线为满足部分开发者业务拓展的诉求，小程序类目已达5个且满足一定条件的帐号可以在后台申请更多类目。 申请方法：登录「微信公众平台小程序」->「设置」->「基本设置」->「服务类目」->「详情」->「申请更多类目」 [图片] 上周问题反馈和处理进度（01.06-01.10）已修复的问题第三方平台请求微信公众号出现系统异常提示的问题 查看详情 本人是小程序的管理员，却无法创建服务平台企业主页的问题 查看详情 【多端统一开发工具——kbone】错别字的问题 查看详情 微信开放平台 创建网站应用无法提交审核的问题 查看详情 小程序后台每隔一分钟就会推送插件更新通知的问题 查看详情 米大师沙箱支付失败，errCode -15004 的问题 查看详情 流量主后台找不到创建的广告位的问题 查看详情 修复中的问题安卓微信7.0.10 分享出去的链接lcalstorage和cookie和未分享出去的链接不共用的问题 查看详情 layaair 网络加载资源的问题 查看详情 用户登录获取到的session_key不到10分钟就失效，导致调用需要虚拟币接口失败的问题 查看详情 2.10.0 picker mode = multiSelector 的 bug 查看详情 toTempFilePathSync 截图后分享图片为黑色的问题 查看详情 社区小程序回答框没有适配 iphone X系列手机的问题 查看详情 iOS 微信7.0.9及7.0.10版本播放音效导致掉帧的问题 查看详情 wx.createInnerAudioContext 拖动或者快进后播放时间超过总时长的问题 查看详情 小程序 code2session 接口返回值和文档的描述不一致的问题 查看详情 回车换行后自动追加很多空格的问题 查看详情 开发工具空白行光标显示错误的问题 查看详情 文案有错误的问题 查看详情 文档中 wx.getSetting 的参数 withSubscriptions 没了的问题 查看详情 iOS 出现极为严重的间歇性卡顿的问题 查看详情 onDeviceOrientationChange 当锁定屏幕旋转时仍能触发的问题 查看详情 社区帖子详情界面表格小问题 查看详情 订阅消息的文档错误的问题 查看详情 报告一处文案错误的问题 查看详情 小程序文档有误 weui 的 msg 组件的问题 查看详情 微信开放文档 第三方平台文档链接为404的问题 查看详情 报告一个文档错误 查看详情 微信语义理解和语音识别的开发指南内容错乱的问题 查看详情 文档页面404的问题 查看详情 需求反馈需求评估中live_pusher 增加一个 logo 水印功能的需求 查看详情 组件教程优化的需求 查看详情 蓝牙发送数据 API 增加参数的需求 查看详情 小程序公众平台-开发-错误查询结果里显示时分秒的需求 查看详情 当要改变组件文件夹名字的时候，有快捷方式更新组件文件夹里面所有文件的名字的需求 查看详情 image 组件的 mode 的需求 查看详情 wx.writeBLECharacteristicValue 的相关需求 查看详情 小程序暂停服务时的提示语可自定义的需求 查看详情 关于小程序调试模式 vConsole 功能，可以增加 network 请求和 localStorage 功能的需求 查看详情 微信团队 2020.01.16

我们知道小程序的wx.request网络接口只支持HTTPS协议（文档-小程序网络说明），为什么HTTPS协议就比HTTP安全呢？一次安全可靠的通信应该包含什么东西呢，这篇文章我会尝试讲清楚这些细节。 Alice与Bob的通信 我们以Alice与Bob一次通信来贯穿全文，一开始他们都是用明文的形式在网络传输通信内容。 [图片] 嗅探以及篡改 如果在他们的通信链路出现了一个Hacker，由于通信内容都是明文可见，所以Hacker可以嗅探看到这些内容，也可以篡改这些内容。 [图片] 公众号的文章之前就遇到很多被挟持篡改了内容，插入广告。 [图片] 加密解密 既然明文有问题，那就需要对明文进行加密处理，让中间人看不懂内容，于是乎要对原来的内容变成一段看不懂的内容，称为加密，反之则是解密。而本质其实就是一种数学运算的逆运算，类似加法减法，例如发送方可以将 abcd…xyz 每个字母+1映射成 bcd…yza，使得原文的字母变成看不懂的序列，而接收方只需要将每个字母-1就可以恢复成原来的序列，当然这种做法规律太容易被破解了，后边会有个案例示意图。 [图片] 对称加密 如果对2个二进制数A和B进行异或运算得到结果C, 那C和B再异或一次就会回到A，所以异或也可以作为加密解密的运算。 [图片] 把操作数A作为明文，操作数B作为密钥，结果C作为密文。可以看到加密解密运用同一个密钥B，把这种加解密都用同一个密钥的方式叫做对称加密。 [图片] 可以看到简单的异或加密/解密操作，需要密钥跟明文位数相同。为了克服这个缺点，需要改进一下，把明文进行分组，每组长度跟密钥一致，分别做异或操作就可以得到密文分片，再合并到一起就得到密文了。 [图片] 但是这种简单分组的模式也是很容易发现规律，可以从下图看到，中间采用对原图进行DES的ECB模式加密（就是上边提到简单分组的模式） [图片] 很明显，原图一些特征在加密后还是暴露无遗，因此需要再改进一把。一般的思路就是将上次分组运算的结果/中间结果参与到下次分组的运算中去，使得更随机混乱，更难破解。以下图片来自维基百科： [图片] 经过改良后，Alice与Bob如果能提前拿到一个对称加密的密钥，他们就可以通过加密明文来保证他们说话内容不会被Hacker看到了。 [图片] 非对称加密 刚刚还引发另一个问题，这个对称加密用到的密钥怎么互相告知呢？如果在传输真正的数据之前，先把密钥传过去，那Hacker还是能嗅探到，那之后就了无秘密了。于是乎出现另外一种手段： [图片] 这就是非对称加密，任何人都可以通过拿到Bob公开的公钥对内容进行加密，然后只有Bob自己私有的钥匙才能解密还原出原来内容。 [图片] RSA就是这样一个算法，具体数学证明利用了大质数乘法难以分解、费马小定理等数学理论支撑它难以破解。相对于前边的对称加密来说，其需要做乘法模除等操作，性能效率比对称加密差很多。 [图片] 由于非对称加密的性能低，因此我们用它来先协商对称加密的密钥即可，后续真正通信的内容还是用对称加密的手段，提高整体的性能。 [图片] 认证 上边虽然解决了密钥配送的问题，但是中间人还是可以欺骗双方，只要在Alice像Bob要公钥的时候，Hacker把自己公钥给了Alice，而Alice是不知道这个事情的，以为一直都是Bob跟她在通信。 [图片] 要怎么证明现在传过来的公钥就是Bob给的呢？在危险的网络环境下，还是没有解决这个问题。 [图片] 一般我们现实生活是怎么证明Bob就是Bob呢？一般都是政府给我们每个人发一个身份证（假设身份证没法伪造），我只要看到Bob身份证，就证明Bob就是Bob。 网络也可以这么做，如果有个大家都信任的组织CA给每个人出证明，那Alice只要拿到这个证明，检查一下是不是CA制作的Bob证书就可以证明Bob是Bob。所以这个证书里边需要有两个重要的东西：Bob的公钥+CA做的数字签名。 [图片] 前边说到用公钥进行加密，只有拥有私钥的人才能解密。数字证书有点反过来：用私钥进行加密，用公钥进行解密。CA用自己的私钥对Bob的信息（包含Bob公钥）进行加密，由于Alice无条件信任CA，所以已经提前知道CA的公钥，当她收到Bob证书的时候，只要用CA的公钥对Bob证书内容进行解密，发现能否成功解开（还需要校验完整性），此时说明Bob就是Bob，那之后用证书里边的Bob公钥来走之前的流程，就解决了中间人欺骗这个问题了。 这种方式也是一种防抵赖的方式，让对方把消息做一个数字签名，只要我收到消息，用对方的公钥成功解开校验这个签名，说明这个消息必然是对方发给我的，对方不可以抵赖这个行为，因为只有他才拥有做数字签名的私钥。 [图片] CA其实是有多级关系，顶层有个根CA，只要他信任B，B信任C，C信任D，那我们基本就可以认为D是可信的。 [图片] 完整性 上边基本上已经解决了保密性和认证，还有一个完整性没有保障。虽然Hacker还是看不懂内容，但是Hacker可以随便篡改通信内容的几个bit位，此时Bob解密看到的可能是很乱的内容，但是他也不知道这个究竟是Alice真实发的内容，还是被别人偷偷改了的内容。 [图片] 单向Hash函数可以把输入变成一个定长的输出串，其特点就是无法从这个输出还原回输入内容，并且不同的输入几乎不可能产生相同的输出，即便你要特意去找也非常难找到这样的输入（抗碰撞性），因此Alice只要将明文内容做一个Hash运算得到一个Hash值，并一起加密传递过去给Bob。Hacker即便篡改了内容，Bob解密之后发现拿到的内容以及对应计算出来的Hash值与传递过来的不一致，说明这个包的完整性被破坏了。 [图片] 一次安全可靠的通信 总结一下，安全可靠的保障： 对称加密以及非对称加密来解决：保密性 数字签名：认证、不可抵赖 单向Hash算法：完整性 来一张完整的图： [图片]