小程序丨为什么小程序开发者需要关注HTTPS 协议深度解析？

微信小程序接入的困境

农历新年将至，微信小程序也如期发布，开发者在接入微信小程序过程中，会遇到以下问题：

小程序要求必须通过 HTTPS 完成与服务端通信，若开发者选择自行搭建 HTTPS 服务，那需要自行 SSL 证书申请、部署，完成 https 服务搭建，效率低流程冗长;且 HTTPS 的 SSL 加解析，对服务器的 CPU 有极大的开销。

不仅仅是小程序，苹果 iOS 平台，Google Android 在 2017 也逐步强制要求开发者使用 HTTPS 接入。HTTPS 似乎是一个绕不开的门槛，让不少开发者头痛不已。

针对以上问题，腾讯云的负载均衡服务(cloud load balance)，希望通过对 HTTPS 的性能优化，提供一键式的 SSL 证书申请服务，降低 HTTPS 的应用门槛和使用成本，让开发者能快速接入微信小程序等服务。首先，先让我们看看 HTTP 与 HTTPS 的对比，逐一解开您的谜团。

HTTP 协议是一个非常简单和高效的协议，互联网大部分的主流应用默认都是使用的HTTP。由于性能和上个世纪 90 年代使用环境的限制，HTTP 协议本身并不是一个为了安全设计的协议，既没有身份认证，也没有一致性检验，最头疼的是，HTTP 所有的内容都是明文传输的。

另外一方面，互联网的发展也是日新月异，各种 HTTP 应用不断地渗透到人们生活的方方面面。不管是社交、购物、金融、游戏、还是搜索，这些 HTTP 服务都能带给人们极大的便捷，提升生活质量和效率。

显然，HTTP 和人们生活及经济利益密切相关，遗憾的是，它不安全。也就意味着这里一 定潜藏着巨大的安全隐患。这些隐患又集中表现在如下两方面：

由于 HTTP 本身是明文传输，用户和服务端之间的传输内容都能被中间者查看。也就是说 你在网上搜索、购物、访问的网点、点击的页面等信息，都可以被「中间人」获取。由于国人大多不太重视隐私的保护，这里的风险比较隐性，伤害后果也不太好定量评估。已知的一些比较严重的隐私泄露事件包括：

• QQ 登陆态被不法分子窃取，然后在异地登陆，进行广告和欺诈行为。

• 用户手机号和身份信息泄露。

• 用户网上行为泄露。比如搜索了一所医院，很快就会有人打电话进行推广(非效果广告)。
  

隐私泄露的风险比较隐蔽，用户基本感知不到。但另外一类劫持的影响就非常明显非常直接了——页面劫持，也就是直接篡改用户的浏览页面。有很多页面劫持很简单粗暴，直接插入第三方广告或者运营商的流量提示信息。

但也有一些劫持做得比较隐蔽，比如下面的京东页面劫持：其中上图是使用 HTTP 方面的页面，顶部箭头所示的地方出现了一个购物推荐，很逼真，就像京东或者浏览器官方的工具。

但换成 HTTPS 访问，就没有这个工具页面，显然是被劫持了。

那劫持到底是如何产生的呢？从技术上来讲比较简单，在内容经过的地方进行监听篡改就行了。但要想把整个劫持的产业链条摸清楚，需要深入黑产内部，比较困难。有一点可以肯定的是，劫持大部分都是在中间的网络节点发生的，又叫「中间人」(MITM， man in the middle)。如下图所示：

由于信息传输都需要经过上述的「中间人节点」，它们又拥有信息的读写权限，如果信息没有加密，也没有校验，那么想要查看隐私，篡改页面，对于「中间人」来说可谓是轻而易举。

那劫持又有哪些主要的分类呢?根据劫持路径划分的话，主要是下图所示的三类：

DNS 劫持，客户端劫持和链路劫持。 根据我们的不完全统计，业务遇到的绝大部分劫持 (90%)都属于链路劫持。

HTTPS 为什么能很好的解决链路劫持呢？主要是三大武器:

每次建立一个全新的 HTTPS 连接时，都需要对身份进行认证，确保用户访问的是正确的目的网站。

内容加密意味端对端的通信内容全都是密文，中间人无法直接查看到明文，HTTPS 所有的应用层内容都是通过对称加密来实现加密和解密的。

通过对数据和共享密钥的 MAC 码来防止中间者篡改消息内容，确保数据的一致性。

事实上 HTTPS 1995 年就诞生了，是一个非常古老、成熟的协议。同时又能很好地防止内容劫持，保护用户隐私。但是为什么一直到今天，还有大部分的网站不支持 HTTPS，只使用 HTTP 呢?

影响 HTTPS 普及的主要原因可以概括为两个字：「慢」和「贵」。

在未经任何优化的情况下，HTTPS 会严重降低用户的访问速度。主要因素包括:

• 网络耗时。由于协议的规定，必须要进行的网络传输。比如 SSL 完全握手，302 跳转等。最坏情况下可能要增加 7 个 RTT。
  

• 计算耗时。无论是客户端还是服务端，都需要进行对称加解密，协议解析，私钥计算，证书校验等计算，增加大量的计算时间。
  

HTTPS 的贵，主要体现在如下三方面：

• 服务器成本。HTTPS 的私钥计算会导致服务端性能的急剧下降，甚至不到 HTTP 协议的十分之一，也就是说，如果 HTTP 的性能是 10000cps，HTTPS 的性能可能只有几百 cps，会增加数倍甚至数十倍的服务器成本。

• 证书成本。根据证书个数及证书类型，一年可能需要花费几百到几百万不等的证书成本。

• 开发和运维成本。HTTPS 协议比较复杂，openssl 的开源实现也经常发生安全BUG， 包括协议的配置，证书的更新，过期监控，客户端的兼容等一系列问题都需要具备专业背景的技术人员跟进处理。

  
  

腾讯云负载均衡器深针对 HTTPS 推广应用过程中的痛点进行了深度优化。接下来我们详细地介绍下这些优化方案：

前文提到 HTTPS 非常慢，我们也主要从两个层面对访问速度进行了优化：协议栈和前后端资源。

HTTPS 可以认为是 HTTP over SSL，而 HTTPS 又是使用 TCP 协议进行传输，所以整个协议栈的优化涉及到三个层面:

• TCP 优化。包括拥塞窗口的调整，tcp fast open，reuseport 的支持，最新的 BBR 拥塞控制算法的支持等。
  

• SSL 协议优化。分布式 session cache, session ticket，False start, ocsp stapling file， 动态 record size 等。
  

SSL 协议优化最重要的目标还是提升简化握手的比例。腾讯云通过实现全局 session cache 和全局 session ticket 来提升 SSL 的简化握手比例，节省用户访问时间和计算资源。

• 应用层协议优化。同时支持 SPDY，HTTP2，HSTS 等。
  

HTTP2 相比 HTTP1.X 最大的优势就是多路复用，能够将多个 HTTP 请求通过一个 TCP 连接并行发送，相比 HTTP1.X 的串行发送，性能无疑是提升很多。

由于 HTTP2 是从 SPDY 继承发展出来的，所以部分较老的客户端只支持 SPDY，不支持 HTTP2。而大部分新客户端，只支持 HTTP2，不支持 SPDY。为了同时兼容新老客户端的性能，腾讯云同时支持 SPDY 和 HTTP2，最大化提升新老版本客户端的性能。

HTTP2 及 SPDY 最大的特性和优势就是多路复用，能够将多个请求通过一个连接并行发送出来。这个特性虽然很强大，但是如果还使用传统的 HTTP 优化策略，多路复用的效果会很有限。比如域名分片，pipline 等都会影响多路复用的效果。于是我们又通过多次的数据实验，调整了一些前端资源包括后端接入的策略：

• 域名收归。通过页面资源及性能分析，确实域名收归方案，比如移动页面不超过 3 个。

• 预建连接。STGW 提供预连接页面，通过对热点页面的用户行为进行分析，提前建立连接，减少协议开销对用户体验的影响。

• 通过腾讯云遍布全球的 CDN 及 IDC 节点就近完成 HTTPS 卸载。
  

针对 HTTPS 的计算性能，腾讯云主要从三个层面进行了优化，包括:

• 尽量减少完全握手的发生，提升简化握手比例。比如前文提到的全局 sessioncache 和 session ticket。

• 对于不可避免的完全握手，腾讯云实现了 RSA 异步代理计算，通过对协议栈的改造和 SSL 硬件加速卡的使用，大幅度提升了 HTTPS 的计算能力和防攻击能力。

• 对称加密计算过程也进行了场景使用上的优化。
  

下面再详细介绍一下：

腾讯云针对 HTTPS 性能消耗最严重的环节——非对称密钥交换算法进行了重点优化。优化思路主要包括如下三部分:

• 算法分离。就是将最消耗 CPU 资源的算法剥离出来，不让消耗本地的 CPU 资源。

• 代理计算。使用空闲的 CPU 机器或者专门的 SSL 硬件加速卡来完成 RSA 计算。

• 异步执行。传统的 openssl 在进行 RSA 的时候，上层应用，比如 NGINX 都需要同步等待。这一步骤也非常影响，必须要进行异步改造，这样在加速集群进行 RSA 计算的时候，接入服务器也可以接入其他用户的请求，提升吞吐能力。

  
  

通过对 openssl 握手协议栈的深度改造以及 SSL 硬件加速卡的 RSA 计算性能，腾讯云 CLB 的 SSL 计算能力提升了 350%。单机 ECDHE_RSA 处理性能达到了 65000 cps。

腾讯云根据应用场景匹配最优的对称加密算法:

• 对于视频等流媒体内容，优先使用 aes-gcm。

• 针对不支持 aes-ni 硬件加速指令的移动终端，使用 chacha20-poly1305 。

• 针对 IE6 等古董级别的客户端，使用 RC4 算法。
  

腾讯云 CLB 支持现在主流的全部 HTTP 类协议接入和卸载。包括：

• http1.0/http1.1

• http2 及前身 spdy3.1

• https,包括 ssl3.0, tlsv1.0,tlsv1.1,tlsv1.2

• websocket 及 secure websocket。

• tcp,udp 透明转发。
  

CLB 能够将上述七层协议统一转换成 HTTP1.1，透传给业务。对业务的好处也非常明显: 0 开发成本就能使用 HTTPS 和 HTTP2，极大减少了适配各种协议和客户端的压力。

安全涉及的领域和场景非常庞大，HTTPS 虽然能够彻底解决链路劫持，但是对于如下两类问题却无能为力:

• CC 攻击，特别是 HTTPS 计算型攻击，HTTPS 的性能会急剧降低，引入更大的安全风险。

• 业务安全，包括 SQL 注入，XSS 跨站、网站挂马等。
  

上述两类都是经常困扰业务的风险极大的安全问题。

针对上述问题，腾讯云也设计实现了一套针对 HTTPS 的防 CC 和 WAF 的安全系统，能够有效地防御这类安全风险。

对证书稍微熟悉的朋友都知道，SSL 密钥和证书都是成对使用的，一个证书一定唯一对应一个私钥。整个 HTTPS 最重要的一个数据就是 SSL 的私钥了，如果私钥泄露，整个握手过程就可以被劫持，签名可以被伪造，对称密钥也可以被破解。整个 HTTPS 就毫无安全可言。

传统的私钥方案就是将私钥和应用程序绑定在一起。比如大家熟知的 nginx, apache，如果想使用 HTTPS，必须在部署 nginx 的接入机器上部署相关的证书和私钥。

这种方案会有如下安全上的问题：私钥部署在云端或者 CDN，如果泄露了怎么办？

虽然腾讯云的内网非常安全，但是出于对客户的安全负责，彻底打消用户对私钥泄露的顾 虑，确保用户对私钥的绝对控制，腾讯云提供一种无私钥的加载方案。这个方案核心是「不需要把私钥存储在腾讯云，允许用户使用自己的服务器保管私钥，完成 HTTPS 的接入」。 腾讯云完全接触不到私钥，客户甚至可以把私钥保存在自己家里的服务器上。

它的接入过程如下：

• 用户发起 HTTPS 握手请求。

• 在涉及到私钥计算的时候，腾讯云 CLB 会将这个私钥计算请求通过加密的自定义协议，转发给用户自己的 keyless 服务器上。

• keyless 服务调用用户的私钥完成计算。

• keyless 服务将计算结果返回给腾讯云 CLB。

• CLB 继续进行 HTTPS 请求的处理。
  

整个过程，腾讯云接触不到 HTTPS 私钥，需要注意一点的，keyless server 是腾讯云提供一个服务端程序，代码开源，用户自主部署，服务端行为用户掌握得一清二楚。

腾讯云 CLB 负载均衡器通过对协议栈及服务端的深度优化，实现了 HTTPS 性能的巨大提升。同时，我们也通过与国际上著名的证书机构合作，极大降低了证书的成本。腾讯云 CLB 在如下几个方面，能够为微信小程序接入带来非常显著的收益：

• 提供一键式的 SSL 证书申请，CLB 负载均衡服务作为 HTTPS 代理，减轻开发负担，让开发者可以专注小程序业务的开发。

• 使用 HTTPS 并不会降低 client 端的访问速度。HTTP、HTTPS 访问时延几乎一致。

• 集群内单台服务器 SSL 加解密性能，高达 6.5Wcps 的完全握手。相比高性能CPU 提升了至少 3.5 倍，节省了服务端成本，极大提升了业务运营及流量突涨时的服务能力， 增强了计算型防攻击的能力。

• 支持多种协议卸载及转换。减少业务适配客户端各种协议的压力，业务后端只需要支持 HTTP1.1 就能使用 HTTP2，SPDY，SSL3.0，TLS1.2 等各版本协议。满足微信小程序，iOS 平台等对协议的要求。

• SSL 证书申请、监控、替换。我们和国际顶级的证书厂商 comodo，symantec 已有深入合作，服务体系完善。

• 防 CC 及 WAF 功能。能够有效杜绝慢连接、高频定点攻击、SQL 注入、网页挂马等应用层攻击。

  
  

以上的这些收益，可以帮助开发者降低 HTTPS 的试用门槛。

【转载说明】   若上述素材出现侵权，请及时联系我们删除及进行处理：8088013@qq.com