WeTest 导读

2017年1月1日起，苹果公司将强制使用 HTTPS 协议传输。本文通过对 HTTPS 基础原理和通信过程内容的讲解，介绍 APP 开发者在这个背景下的应对办法。

---

几周前，我们在《https 大势已来？看腾讯专家如何在高并发压测中支持 https》中介绍了腾讯 WeTest 在基于 epoll 的高并发机器人框架中加入 openssl 的方法支持 HTTPS 接口测试的方法，不仅介绍了具体的使用办法，并且了解到 HTTPS 注定会是未来的主流趋势。

而随着 2016 年行将结束，我们发现，这一天，已经越来越近了。

随着全球互联网安全意识的进一步觉醒，越来越多的公司意识到网络信息安全的重要性，只有绝对的加密才能保证在线交易和商务活动的安全进行。互联网无疑是个人信息和隐私泄露最频繁的场合，各种以窃取信息为方式而展开的网络犯罪是互联网发展所面临的最大挑战。在这样一个大环境下，苹果公司首先做出应对，在苹果全球开发者大会（WWDC）的一场安全演示会上，苹果公司公布了一个最后期限——2017年1月1日——即 App Store 当中的所有应用必须启用 App Transport Security（ATS）安全功能。

一、这个举措意味着什么？

苹果公司强制所有 iOS App 在2017年1月1日前使用 HTTPS 加密，这就意味着，如果您的 APP 如果仍采用 HTTP 传输，那么，在 Apple Store 中您的 APP 将不再能被用户下载使用。

二、什么是 App Transport Security（ATS）安全功能？

App Transport Security，简称 ATS，是苹果在 iOS 9 当中首次推出的一项安全功能。在启用 ATS 之后，它会强制应用通过 HTTPS（而不是 HTTP）连接网络服务，这能够通过加密来保障用户数据安全。

HTTPS 当中的 “S” 代表的是 “安全”（secure），在登录银行或电邮账号时，你会常常看到它出现在浏览器地址栏。不过，移动应用在网络连接安全性上面没有那么透明，用户很难知道应用连接网络时使用的是 HTTP 还是 HTTPS。

ATS 由此登场，它在 iOS 9 当中是默认开启的。然而，开发者仍然能够关闭 ATS，让自己的应用通过 HTTP 连接传输数据——现在的情况是，这招在年底之后就行不通了。（技术人员注意：ATS 要求使用 TLS v 1.2，但那些已经经过加密的批量数据例外，比如流媒体数据。）

在今年年底时，苹果将要求所有提交到 App Store 的应用强制开启 ATS。现在有了明确的最终期限，那些一直 想知道 HTTP 会在什么时候遭此重击的应用开发者可以松一口气了，而用户也能安心地知道，他们的 iPhone 和 iPad 应用将默认使用安全连接。

三、为什么这么做？

企业对于网络信息安全的也越来越高，只有保证绝对的加密传输才能确保在线交易及用户个人隐私数据的安全性。由于 HTTP 明文传输带来的安全事件频发，企业对于 HTTP 已无信任可言，只有通过 HTTPS 加密传输才能有效的防钓鱼，防篡改，防监听，防劫持使网站安全可信。

四、开发者应该做什么？

首先需要选择合适的证书为部署 https 证书做决策，然后调整后台应用实现后台应用全站 https，协调运营及开发完成部署完善服务端应用部署及 Web 服务器配置，最后以安全方式发布应用完成应用改造，重新发布应用。

为了让大家更好的理解上述措施，下面具体介绍一下相关的 HTTPS 基础原理和通信过程。

五、HTTPS 的基础原理和通信过程

HTTPS(Secure Hypertext Transfer Protocol) 安全超文本传输协议 它是一个安全通信通道，它基于 HTTP 开发，用于在客户计算机和服务器之间交换信息。它使用安全套接字层 (SSL) 进行信息交换，简单来说它是 HTTP 的安全版,是使用 TLS/SSL 加密的 HTTP 协议。

HTTP 协议采用明文传输信息，存在信息窃听、信息篡改和信息劫持的风险，而协议 TLS/SSL 具有身份验证、信息加密和完整性校验的功能，可以避免此类问题。

TLS/SSL 全称安全传输层协议 Transport Layer Security, 是介于 TCP 和 HTTP 之间的一层安全协议，不影响原有的 TCP 协议和 HTTP 协议，所以使用 HTTPS 基本上不需要对 HTTP 页面进行太多的改造。

1、TLS/SSL 原理

HTTPS 协议的主要功能基本都依赖于 TLS/SSL 协议，本节分析安全协议的实现原理。

TLS/SSL 的功能实现主要依赖于三类基本算法：散列函数 Hash、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。

散列函数 Hash，常见的有 MD5、SHA1、SHA256，该类函数特点是函数单向不可逆、对输入非常敏感、输出长度固定，针对数据的任何修改都会改变散列函数的结果，用于防止信息篡改并验证数据的完整性；对称加密，常见的有 AES-CBC、DES、3DES、AES-GCM 等，相同的密钥可以用于信息的加密和解密，掌握密钥才能获取信息，能够防止信息窃听，通信方式是 1 对 1；非对称加密，即常见的 RSA 算法，还包括 ECC、DH 等算法，算法特点是，密钥成对出现，一般称为公钥 (公开) 和私钥 (保密)，公钥加密的信息只能私钥解开，私钥加密的信息只能公钥解开。因此掌握公钥的不同客户端之间不能互相解密信息，只能和掌握私钥的服务器进行加密通信，服务器可以实现 1 对多的通信，客户端也可以用来验证掌握私钥的服务器身份。

在信息传输过程中，散列函数不能单独实现信息防篡改，因为明文传输，中间人可以修改信息之后重新计算信息摘要，因此需要对传输的信息以及信息摘要进行加密；对称加密的优势是信息传输 1 对 1，需要共享相同的密码，密码的安全是保证信息安全的基础，服务器和 N 个客户端通信，需要维持 N 个密码记录，且缺少修改密码的机制；非对称加密的特点是信息传输 1 对多，服务器只需要维持一个私钥就能够和多个客户端进行加密通信，但服务器发出的信息能够被所有的客户端解密，且该算法的计算复杂，加密速度慢。

结合三类算法的特点，TLS 的基本工作方式是，客户端使用非对称加密与服务器进行通信，实现身份验证并协商对称加密使用的密钥，然后对称加密算法采用协商密钥对信息以及信息摘要进行加密通信，不同的节点之间采用的对称密钥不同，从而可以保证信息只能通信双方获取。

2、PKI 体系

（1）RSA 身份验证的隐患

身份验证和密钥协商是 TLS 的基础功能，要求的前提是合法的服务器掌握着对应的私钥。但 RSA 算法无法确保服务器身份的合法性，因为公钥并不包含服务器的信息，存在安全隐患：

客户端 C 和服务器 S 进行通信，中间节点 M 截获了二者的通信；

节点 M 自己计算产生一对公钥 pub_M 和私钥 pri_M;

C 向 S 请求公钥时，M 把自己的公钥 pub_M 发给了 C;

C 使用公钥 pub_M 加密的数据能够被 M 解密，因为 M 掌握对应的私钥 pri_M，而 C 无法根据公钥信息判断服务器的身份，从而 C 和 M 之间建立了” 可信” 加密连接；

中间节点 M 和服务器 S 之间再建立合法的连接，因此 C 和 S 之间通信被 M 完全掌握，M 可以进行信息的窃听、篡改等操作。

另外，服务器也可以对自己的发出的信息进行否认，不承认相关信息是自己发出。

因此该方案下至少存在两类问题：中间人攻击和信息抵赖。

几周前，我们在《https 大势已来？看腾讯专家如何在高并发压测中支持 https》中介绍了腾讯 WeTest 在基于 epoll 的高并发机器人框架中加入 openssl 的方法支持 HTTPS 接口测试的方法，不仅介绍了具体的使用办法，并且了解到 HTTPS 注定会是未来的主流趋势。

而随着 2016 年行将结束，我们发现，这一天，已经越来越近了。

随着全球互联网安全意识的进一步觉醒，越来越多的公司意识到网络信息安全的重要性，只有绝对的加密才能保证在线交易和商务活动的安全进行。互联网无疑是个人信息和隐私泄露最频繁的场合，各种以窃取信息为方式而展开的网络犯罪是互联网发展所面临的最大挑战。在这样一个大环境下，苹果公司首先做出应对，在苹果全球开发者大会（WWDC）的一场安全演示会上，苹果公司公布了一个最后期限——2017年1月1日——即 App Store 当中的所有应用必须启用 App Transport Security（ATS）安全功能。

（2）身份验证-CA 和证书

解决上述身份验证问题的关键是确保获取的公钥途径是合法的，能够验证服务器的身份信息，为此需要引入权威的第三方机构 CA。CA 负责核实公钥的拥有者的信息，并颁发认证” 证书”，同时能够为使用者提供证书验证服务，即 PKI 体系。

基本的原理为，CA 负责审核信息，然后对关键信息利用私钥进行” 签名”，公开对应的公钥，客户端可以利用公钥验证签名。CA 也可以吊销已经签发的证书，基本的方式包括两类 CRL 文件和 OCSP。CA 使用具体的流程如下：

a.服务方 S 向第三方机构 CA 提交公钥、组织信息、个人信息 (域名) 等信息并申请认证；

b.CA 通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等；

c.如信息审核通过，CA 会向申请者签发认证文件 - 证书。

证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名；

签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA 的私钥对信息摘要进行加密，密文即签名；

d.客户端 C 向服务器 S 发出请求时，S 返回证书文件；

e.客户端 C 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法；

f.客户端然后验证证书相关的域名信息、有效时间等信息；

g.客户端会内置信任 CA 的证书信息 (包含公钥)，如果 CA 不被信任，则找不到对应 CA 的证书，证书也会被判定非法。

在这个过程注意几点：

1.申请证书不需要提供私钥，确保私钥永远只能服务器掌握；

2.证书的合法性仍然依赖于非对称加密算法，证书主要是增加了服务器信息以及签名；

3.内置 CA 对应的证书称为根证书，颁发者和使用者相同，自己为自己签名，即自签名证书；

4.证书=公钥 + 申请者与颁发者信息 + 签名；

六、HTTPS 接口测试

那么在完成了全站 HTTPS，完成了后台和服务器端的部署之后，如何快速的对 “新站 “进行快速的测试，检测 APP 接口的承载能力？

腾讯 WeTest 提供了针对 https 的服务器性能测试功能，使用方法如下：

1、点击服务器性能测试产品首页（http://wetest.qq.com/gaps/ ）中的快捷入口：HTTP 直压。模式选择简单模式，名称和描述可以自己填写。（图中示例起始人数 50 人，每隔 60 秒增加 50 人，加到 200 人为上限）

点击左侧 “HTTP 直压 “进入压测

2、新建一个客户端请求，接口压测包括读写接口，读接口基本是 GET 请求，写接口基本是 POST 请求。GET 请求使用 url 请求参数，填写测试用例的基础数值，选择正确的 URL

配置页面 header 信息

3、随后进行 Header 的配置，Header 的名称在选定 URL 的内，打开 URL 的链接（推荐使用 chrome 浏览器），敲击 F12 并刷新页面，选定 Network-Name-Headers-Request Headers（Header 的名称与值均在内查看，如下图所示）

查看页面 header 信息

到这里，基本就完成了对 https 的配置过程了，是不是很简单？下面动图可以再回顾一下操作的流程：

gif 动态图展示操作的流程

七、HTTPS 性能与优化

在对 HTTPS 协议页面进行了测试之后，下面再介绍一些 HTTPS 页面性能优化的方法。

1、HTTPS 性能损耗

HTTPS 的优势在于进行完身份验证、信息加密与完整性校验等操作后，可以不对 TCP 和 HTTP 协议做任何修改。但通过增加新协议以实现更安全的通信必然需要付出代价，HTTPS 协议的性能损耗主要体现如下：

（1）增加延时

分析前面的握手过程，一次完整的握手至少需要两端依次来回两次通信，至少增加延时 2 RTT，利用会话缓存从而复用连接，延时也至少 1 RTT*。

（2）消耗较多的 CPU 资源

除数据传输之外，HTTPS 通信主要包括对对称加解密、非对称加解密 (服务器主要采用私钥解密数据)；压测 TS8 机型的单核 CPU：对称加密算法 AES-CBC-256 吞吐量 600Mbps，非对称 RSA 私钥解密 200 次/s。不考虑其它软件层面的开销，10G 网卡为对称加密需要消耗 CPU 约 17 核，24 核 CPU 最多接入 HTTPS 连接 4800；

静态节点当前 10G 网卡的 TS8 机型的 HTTP 单机接入能力约为 10w/s，如果将所有的 HTTP 连接变为 HTTPS 连接，则明显 RSA 的解密最先成为瓶颈。因此，RSA 的解密能力是当前困扰 HTTPS 接入的主要难题。

2、HTTPS 接入优化

（1）CDN 接入

HTTPS 增加的延时主要是传输延时 RTT，RTT 的特点是节点越近延时越小，CDN 天然离用户最近，因此选择使用 CDN 作为 HTTPS 接入的入口，将能够极大减少接入延时。CDN 节点通过和业务服务器维持长连接、会话复用和链路质量优化等可控方法，极大减少 HTTPS 带来的延时。

（2）会话缓存

虽然前文提到 HTTPS 即使采用会话缓存也要至少 1*RTT 的延时，但是至少延时已经减少为原来的一半，明显的延时优化；同时，基于会话缓存建立的 HTTPS 连接不需要服务器使用 RSA 私钥解密获取 Pre-master 信息，可以省去 CPU 的消耗。如果业务访问连接集中，缓存命中率高，则 HTTPS 的接入能力讲明显提升。当前 TRP 平台的缓存命中率高峰时期大于 30%，10k/s 的接入资源实际可以承载 13k/的接入，收效非常可观。

（3）硬件加速

为接入服务器安装专用的 SSL 硬件加速卡，作用类似 GPU，释放 CPU，能够具有更高的 HTTPS 接入能力且不影响业务程序的。测试某硬件加速卡单卡可以提供 35k 的解密能力，相当于 175 核 CPU，至少相当于 7 台 24 核的服务器，考虑到接入服务器其它程序的开销，一张硬件卡可以实现接近 10 台服务器的接入能力。

（4）远程解密

本地接入消耗过多的 CPU 资源，浪费了网卡和硬盘等资源，考虑将最消耗 CPU 资源的 RSA 解密计算任务转移到其它服务器，如此则可以充分发挥服务器的接入能力，充分利用带宽与网卡资源。远程解密服务器可以选择 CPU 负载较低的机器充当，实现机器资源复用，也可以是专门优化的高计算性能的服务器。当前也是 CDN 用于大规模 HTTPS 接入的解决方案之一。

（5）SPDY/HTTP2

前面的方法分别从减少传输延时和单机负载的方法提高 HTTPS 接入性能，但是方法都基于不改变 HTTP 协议的基础上提出的优化方法，SPDY/HTTP2 利用 TLS/SSL 带来的优势，通过修改协议的方法来提升 HTTPS 的性能，提高下载速度等。

---

腾讯 WeTest 服务器性能测试运用了沉淀十多年的内部实践经验总结，通过基于真实业务场景和用户行为进行压力测试，帮助游戏开发者发现服务器端的性能瓶颈，进行针对性的性能调优，降低服务器采购和维护成本，提高用户留存和转化率。

功能目前免费对外开放中，欢迎大家的体验
体验地址：http://WeTest.qq.com/gaps/

如果对使用当中有任何疑问，欢迎联系腾讯 WeTest 企业 qq：800024531